feat(minor): Use Swift 6's isolated(any) feature to unblock the main actor and run benchmarks in whatever isolation context they require (#358)

[wadetregaskis]

Description

See #358 for full details, but in short: previously, the main thread / actor was being blocked by a wait on a semaphore inside runAsync, which meant any benchmark which relied on executing something on the main thread / actor / queue would deadlock.

Now, the main actor / thread / queue is not blocked - and furthermore, benchmarks can annotate themselves with a global actor (e.g. @MainActor) and be run there directly, by the Benchmark framework.

How Has This Been Tested?

I added three new unit tests covering two critical cases:

1. Make sure a @MainActor benchmark runs on the main actor.
2. Make sure a 'regular' (no-specific-isolation) benchmark can hop to the main actor / queue explicitly. In both sync and async versions.

(hopefully the explicit-hop case is made uncommon by being able to just @MainActor the benchmark to begin with, but the big concern is the indirect use of code which does that, such as in some library or deep down a callchain)

Note: I've only tested this with Swift 6.2.4 on Sequoia.

Minimal checklist:

• ✅ I have performed a self-review of my own code
• N/A I have added DocC code-level documentation for any public interfaces exported by the package
• ✅ I have added unit and/or integration tests that prove my fix is effective or that my feature works

[supersonicbyte]

Awesome, thanks for the contribution!

Just a few concerns:

• Should we also add the @isolated(any) annotations to the synchronous BenchmarkClosure so we capture isolation of sync functions? It would force us then to await them, since they could change the isolation, but then we would capture isolation even from functions like this:

let closure = { @MainActor in
   print("hello")
}

• There are some convenience initializers in Benchmark+ConvinienceInitializers.swift which need additional @isolated(any) annotations in order to capture the isolation properly

• With these changes we could should drop the Package@swift-5.9.swift and rename it to Package@swift-6.0.swift.