entt/TODO

* long term feature: templated generic vm
* long term feature: shared_ptr less locator
* long term feature: shared_ptr less resource cache
* custom allocators and EnTT allocator-aware in general (long term feature, I don't actually need it at the moment) - see #22
* debugging tools (#60): the issue online already contains interesting tips on this, look at it
* runner proposal: https://en.wikipedia.org/wiki/Fork%E2%80%93join_model https://slide-rs.github.io/specs/03_dispatcher.html
* work stealing job system (see #100)
  - mt scheduler based on const awareness for types
* meta: sort of meta view based on meta stuff to iterate entities, void * and meta info objects
* allow for built-in parallel each if possible
* allow to replace std:: with custom implementations
* remove runtime views, welcome reflection and what about snapshot?
* empty components model allows for shared components and prefabs unity-like
  - each with entity return the shared component multiple times, one per entity that refers to it
  - each components only return actual component, so shared components are returned only once
* types defined at runtime that refer to the same compile-time type (but to different pools) are possible, the library is almost there
* add opaque input iterators to views and groups that return tuples <entity, T &...> (proxy), multi-pass guaranteed
* add fast lane for raw iterations, extend mt doc to describe allowed add/remove with pre-allocations on fast lanes
* registry.each<T...>(first, last) by iterators, entities/components guaranteed
* multi component registry::remove and some others?
* can I use opaque connection also for the emitter?
* built-in support for dual (or N-) buffering

TODO
* custom (decoupled) pools ==> double buffering, shared components, multi-model
* use direct access (pool-like) also for context variables
* add take functionality, eg registry.take(entity, other); where it takes the entity and all its components from registry and move them to other
* add merge functionality, eg you have entity with A-B, and "apply" a clone from an entity with B-C. B gets replaced, C gets added, and A stays
  - cloning all/part of the components are both required and a target entity on which to stomp your stuff could help
  - clone is just clone, creating new entity. But yeah, both "clone-all", and "clone-components"
  - for "apply", again both All and Components, and maybe an enum of what kind of apply "dont overwrite, overwrite, add-only"
* meta: copy on aliasing should make an actual copy of the value, not of the pointer (steal has a similar problem)
* meta: almost always aliasing method