This switches our ECS over to manually managed memory (1 `[]u8` per archetype table,
with multiple column arrays packed into it - dealing with padding/alignment ourselves)
rather than the prior 1 `ArrayList(Component)` per component in an archetype table.
This idea was discussed in depth in [#ecs:matrix.org](https://matrix.to/#/#ecs:matrix.org)
(thanks Levy!) Notable advantages from my POV:
1. This means we don't need an `ErasedComponentStorage` interface, which is nice.
2. It means component storage does not have to have a Zig type. It could e.g. in theory enable
the ECS to be usable from other languages (C, WebAssembly plugins, etc.) with component types
defined in those languages in the future.
3. It reduces some overhead `ArrayList` has: slice ptr+len+capacity integers per component
array per table
4. It guarantees component arrays are contiguous memory, rather than relying on the allocator
to hopefully provide that (may not hold true in multi-threaded large-allocation situations.)
5. It means we could easily optimize for tables that have very few components by allocating exact
memory for them (could've done this with `ArrayList` too, but now it's more likely the
allocation are larger and thus more reusable by future archetype tables.) This could be quite
important because one can imagine ending up with many small archetype tables.
Overall seems like the right thing to do, so we're doing it.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
334ed5c25f