ECS improvements

[JessyDL]

Following are a list of features that should be investigated or added to the ECS implementation:

• [x] #63
• [x] #64
• [x] #79
• [x] #65
• [x] #80
• [x] #93
• [x] #90
• [x] #94
• [x] #97
• [x] #98
• [ ] #102
• [ ] #103

Extra:

• [ ] Look into alias components. These components could shadow, or alias one-another (see core::ecs::components::transform issue in internal docs)
• [ ] Look into duplicate component support (i.e. multiple same components on same entity). This could be handled as a compile time setting with a set max size, or potentially unbounded size.
• [ ] Alternatively from alias components, look into "concept" types, i.e. components that satisfy a specific concept (like TransformConcept for anything that has a world space position) being grouped and sent as their shared trait data.
• [ ] indirect_t packs spend a large amount of time in lookups even when the underlying storage has not changed. We could consider a "generation_version" variable to mark when the underlying storage has not changed in meaningfull ways so that previous lookups can be re-used

[JessyDL]

Note #64 was resolved in a way that allows us to mix and match complex and trivial component types. This resulted in #63 becoming unnecessary.

As a followup, due to the constraints of std::is_trivial, and the differing constraints we have, we should look into allowing the creation of a "prototype" for trivial component types. This would allow us to have components with a set default value, while still satisfying std::is_trivial.

As new component types are created from a "known" position only (as in, known from the type system's perspective), or when deserializing from "known data", this is a problem we need to satisfy for types when they are deserialized. The language mandates that only types that satisfy std::is_trivially_constructible and std::is_trivially_destructible ( p0593r5 ) can be implicitly created.