ECS metadata stores should operate on `Pin<&mut T>`

## What problem does this solve or what need does it fill?
#10756 highlighted `std::mem::swap` and `std::mem::take` as potential venues for unsoundness: moving the metadata out of the World invalidates the metadata stores, which the entire rest of the ECS implementation relies on.

## What solution would you like?
Use the tools that Rust gives us to prevent trivial moves: `std::pin::Pin`. Core metadata stores like `Components`, `Archetypes`, `Bundles`, etc. should minimize mutable access, and only return mutable access in the form of `Pin<&mut T>` instead of `&mut T`.

Note this likely means the `Index`/`IndexMut` implementations for these various metadata stores will need to go away, as they require `&mut T` to be returned.

bevy_ecs already follows the practices of not exposing any mutable access to metadata stores in it's public interface, but I'm of the opinion that the internal APIs should be no different either. There are quite a few cases of `pub(crate)` access that should be minimized where possible.

## What alternative(s) have you considered?
Returning wrappers around `&mut ComponentInfo` and the other metadata. Requires much more code to implement.

No files or tests are named; begin by surveying the bevy_ecs metadata stores, including Components, Archetypes, and Bundles, and their internal mutable-access and Index/IndexMut APIs. Compare the existing public-interface restrictions with pub(crate) access, then verify that the stores expose pinned mutable access without the noted move hazards.

Written by the indexing model from the issue text.