ECS internals store sizes/capacities they can't reach on 64-bit builds

## What problem does this solve or what need does it fill?
There are several places where the ECS metadata stores lengths and capacities in excess of what they can realistically hold. `Vecs` are used in the following locations:

* `Entities` store of metadata.
* `Archetype` entities.
* `Table` entities.
* `ComponentSparseSet` dense vecs.
* `SparsSets` containing entity-related metadata.
* One-to-many relations components.

Vecs store their length and capacity as `usize`s, which, on 64-bit builds, store a full 8 bytes when only 4 of them will ever be used by any Bevy app as there can only be up to `u32::MAX - 1` entities at any given instant in time.

All of these are fairly hot data types that are all regularly fetched in every interaction with the ECS. The larger these types are, the less cache efficient the entire engine is. Ideally, the entirety of all ECS metadata (sans SparseArray overhead) should be able to fit into the L2 or L3 cache of modern CPUs for any reasonable production application.

If we pursue further examples of X as Entities, this will further proliferate outside the ECS too.

## What solution would you like?
A `Vec32` type that stores its length and capacity as u32s. This would reduce their stack size to 16 bytes (in line with `Box<[T]>` on 64-bit builds). Use them in all of the spaces mentioned above. This shouldn't be too much additional work to implement it on top of the existing `ThinArrayPtr` we already have.

Optionally also include a `BoxedSlice32` that does the same with `Box<[T]>`, but it's questionable if this will result in any actual layout improvements, as by itself it would result in no change to stack size due to the alignment requirements, but that might work in larger types.

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