Switch to using static async executors

## What problem does this solve or what need does it fill?
An investigation in https://github.com/smol-rs/async-executor/issues/91 found that the lock on `async_executor`'s state can have significant overhead when spawning new tasks in large batches, something that both `MultithreadedExecutor` and `Query::par_iter` heavily rely on.

## What solution would you like?
Use the APIs implemented in https://github.com/smol-rs/async-executor/pull/92 to batch spawn tasks in both the `MultithreadedExecutor` and `Query::par_iter`.

Alternatively, https://github.com/smol-rs/async-executor/pull/112 eliminates the cost of the lock entirely, but switching to use a static executor will require additional user-facing API changes.

## What alternative(s) have you considered?
Leaving it as is.

## Additional context
This will likely require shuffling how we spawn tasks in the mulithreaded executor so that we do not end up holding the async_executor lock for longer than necessary. `Query::par_iter` doesn't have these issues and it should be fairly trivial to integrate.

In their current state, we may need have a type implement `Extend>` that just takes receives and detaches the spawned tasks to avoid roping the allocator into the loop.