zzre: Rework asset loading

[Helco]

There is a new implementation of an AssetRegistry, but before merging I want to extensively test this. Therefore we have:

• [x] Basic implementation
• [x] Basic testing
• [x] Figure out concept for sound samples("local assets", not to be shared outside of context)
• [x] Figure out concept for sound streams("highly-local assets", single consumer, manage them centrally at all?)
  Yes manage them entirely locally.
  Or not. With ActorMaterialAsset there is enough reason to introduce AssetLocality
• Migrate game
  • [x] Clumps
  • [x] Actors
  • [x] World
  • [x] Effect
  • [x] UI
  • [x] Sound
  • ~Database?~ Maybe later
• Migrate editors
  • [x] Model
  • [x] Actor
  • [x] World
  • [x] Scene
  • [x] Effect
• [x] Documentation
• [x] Remove IAssetLoader and all AResourceManager
• [x] Retest on Windows, Linux, Mac

Old comment

Another somewhat large rework, this time the way assets are loaded and kept alive, as the current way with mostly using `ManagedResource` except when not bothers me immensely. Other issues briefly written down in the issue were: - No deferred application of assets (meaning definitely no asynchronous loading) - No asynchronous or parallel loading - No model of asset dependencies - No checking that `TAsset` and `TInfo` (now `TQuery`) actually have a loader registered - No deferred unloading of assets - No statistics However I found that the general ECS memory model works well enough for my design, so it is used internally. This should also allow us to add it to `ECSExplorer` for further debugging purposes. However² the implementation sketches show a deeper problem which is OneToMany / ManyToMany relationships which are badly supported by DefaultEcs at this time. I might invest into a "RefittedEcs" to correct this and other shortcomings A quick alternative thought: Creating and disposing resources will inevitably allocate and deallocate memory, additional (relatively tiny) allocations regarding dependency management or even resource state management should be negligible. This is strengthen by the fact that this dynamic memory is probably not often accessed. Meaning: maybe we can use a more naive approach and concentrate on getting the API right.

Fixes #180

[Helco]

Okay, third (or fourth?) design:

Constraints:

• Loading can be asynchronous
• Unloading can be delayed
• Creating handles to loaded assets does not allocate
• Assets may request secondary assets
  • Completion of primary asset loading is delayed until all secondary assets are loaded
  • Application is not necessary for secondary assets
  • However secondary assets shall be applied before primary ones
• Assets (and asset registries) have locality:
  • Global is shared across all game and editor instances
    • Textures
    • Geometry
    • Scenes
  • Context is shared across a single game or editor instance
    • Materials (they depend on stuff like the view/projection matrices)
    • Audio samples (they have to created at the OpenAL Context)
  • SingleUsage assets are never shared. Examples for this are:
    • Streamed audio, the asset state is dependent on the usage (not yet implemented)
    • Actor materials, specifically the pose binding and therefore resource sets cannot be shared

[Helco]

First measurable results: With only backdrops, models and FOModels migrated we have gone from loading 156 textures for sc_2411 to just 11. When transitioning to sc_2421 we only load 2 textures. Currently however none of this is async as seemingly textures are loaded too fast relative to the other stuff.