Custom component storage

Currently, all components of each type are stored within each chunk as a single slice, accessed by what is essentially a custom vtable. This is implemented this way primarily to support a future c-api, where legion may be asked to handle external data types that are not statically known to the rust compiler.

Storage logic for each component could be delegated to a custom storage type, specified via an associated type on the `Component` trait. A default implementation may be similar to the existing code, but with a static type (which would allow for some further compiler optimisations in some situations), and the existing untyped storage logic could be provided for external types. Custom storages could be specified by overriding this type via specialization (or we could use a feature-flag to disable the blanket component implementation).

These storages would each be responsible for storing all of the components of a single type for a single chunk. They would be required to provide all logic for component insertion and removal, and for moving components between chunks during defragmentation and entity component addition/removal. They would be required to provide iterators over all components stored, and to provide indexers to components by the index of an entity within the chunk. Chunks returned via the query API will provide direct (strongly typed) access to each component's storage.

The motivation for this is to allow component types to decompose arrays of themselves into a structure of arrays. This would allow a storage to expose each sub-element slice when accessed via the chunk API, allowing for easier use of SIMD instructions. Such storages would construct and de-construct their higher-level component representations when the storage is accessed.

e.g. a `Position` component, made out of `x`, `y` and `z` floating point elements, would provide a storage implementation which internally stores all `x`, `y` and `z` elements in their own arrays. The storage would yield `Position` types when accessed through the usual APIs, but the user could access the storage directly via `chunk.get_component_storage::().get_x()`, and use 3rd party SIMD libraries to process many entities in the chunk at once. We could perhaps provide a procedural macro to implement this decomposed storage automatically.

It could also potentially be used by a component to implement a more memory-compact representation of `Option` components that are expected to be sparsely populated.