v4: Consolidate ProcessInParallel overloads into one API

[thomhurst]

Problem

ProcessInParallel has an overload landmine:

• ProcessInParallel(100) binds the int overload and creates RateLimitedParallelAsyncProcessor
• ProcessInParallel(maxConcurrency: 100) binds the int? overload and creates ParallelAsyncProcessor with a concurrency limit

Two near-identical call sites choose different processors purely through overload resolution. Since PR #332 both paths run on the same WorkerPool internals, so the split is now purely an API artifact: two public types, two overload families, one behaviour.

Proposal

As part of the v4 breaking window:

• One method shape, e.g. ProcessInParallel(int? maxConcurrency = null) (null = unbounded), with scheduleOnThreadPool kept as an optional argument for the unbounded path only.
• Collapse RateLimitedParallelAsyncProcessor* into ParallelAsyncProcessor* (or keep the type as an alias and mark [Obsolete] for one release).
• README updated to describe one concept: "parallel with an optional concurrency limit".

Acceptance criteria

• A single documented way to request throttled parallel processing.
• Existing tests (rate-limit obeyed, worker-pool behaviour, cancellation) pass against the consolidated API.