Requiring mutable access to several common shared types prevents queue phase parallelization.

## What problem does this solve or what need does it fill?

`Query<&mut RenderPhase>`, `RenderPipelineCache`, `SpecializedPipelines` (to a lesser degree) requires mutable access to use. Each of these can limit the parallelism of the queue phase when rendering.

- `Query<&mut RenderPhase>` limits it to one system per phase at a time. Generally allows parallelism across mutliple phases at the same time, unless there is one system that requires access to multiple render phases.
- `RenderPipelineCache` limits any dependent pipeline from parallelizing.
- `SpecializedPipelines` limits parallelization across multiple phases within a single extract-prepare-queue pipeline. This is less of an issue than the other two.

## What solution would you like?

- Merge `SpecializedPipelines` functionality into `RenderPipelines` and make it generic over a `SpecializedPipeline`. This removes the global pipeline cache as a blocking requirement. Might also improve the ergonomics of writing those kinds of systems.
- Switch any/all of the associated types to use internal mutability. Most notably `RenderPhase` might benefit the most from this. Adding mutexes may be too much of a cost here. Perhaps a good place to try out lock-free data structures? Worth benchmarking.

## What alternative(s) have you considered?

- Recreate render pipelines on every executions.
- Limit time in each queue job by aggressively batching it's inputs in the prepare phase.

Start by locating RenderPhase, RenderPipelineCache, SpecializedPipelines, and RenderPipelines, then trace how they are accessed during the extract-prepare-queue pipeline. Compare the proposed merge and internal-mutability approaches, including their effects on queue-phase parallelism and locking costs. Done means an agreed design is implemented and its parallelism and performance effects are benchmarked.

Written by the indexing model from the issue text.