MPI: keep tasks with acceleration=DistributedAcceleration() rank-local

[AnnaLena77]

Fixes #778.

Under accelerate!(:mpi), tasks spawned with acceleration=DistributedAcceleration() (or inside with_options(; acceleration=DistributedAcceleration())) are meant to run only on the rank that spawns them. Two things broke that when ranks spawn such tasks independently:

• Placement: accel_matches_proc(::DistributedAcceleration, proc) is true for every processor, and compatible_processors(::DistributedAcceleration, ...) skipped the filter completely. Some of these tasks were placed on MPIProcessors, sometimes on another rank, and then never ran. This PR excludes MPI processors for DistributedAcceleration in MPIExt and removes the shortcut, so the generic filter applies.
• Task IDs: these tasks took IDs from the same counter as uniform tasks, and MPI tags are derived from those IDs. With different numbers of local tasks per rank, later uniform tasks got different IDs on each rank and hung. Under uniform execution, tasks with a non-uniform acceleration now take IDs from a separate range (LOCAL_ID_COUNTER, starting at typemax(Int) ÷ 2).

Tests: test/mpi/rank_local.jl (included in test/mpi/cpu.jl) spawns a different number of local tasks on every rank, both ways, checks that they run on ThreadProcs of their own rank, then runs uniform work with cross-rank data, and checks that a local task can use a uniform result owned by its own rank. Without the fix it fails (tasks on MPI processors, Non-uniform value, hangs); with it, it passes. The full test/mpi/cpu.jl passes on 2 ranks × 2 threads (MPICH_jll, macOS).

Not covered: a local task using a uniform result owned by another rank fails with an error, and passing a local task's result back into uniform work isn't addressed here.

Written with help from Claude (Anthropic); I checked the results.

[jpsamaroo]

Thanks for this! I'm not approving or rejecting this PR - I need some time to figure out the design, and then we can come back to this.

[jpsamaroo]

This makes me quite uncomfortable - I want to think more on the design before committing to something like this.

[jpsamaroo]

I think this will cause an increase in allocations, as it was a fast-path avoiding Set allocation.