RenderAssets indirectly owning GPU Resources.

[larsraph]

My understanding of the RenderAsset trait is that it owns GPU resources. However multiple implimentations... mainly MeshAllocator use a interesting system of indirection. Instead of MeshAllocator giving handles that can be used to access the buffer they internally map AssetIds to resources. If we give out handles instead of mapping on the key of the associated resource a two things will happen

1. It will probably be faster because the handles can point into a generationed vector instead of a hashmap with hashing and collision overhead.
2. Ownership of resources will be clearer. EX. Inside the RenderMesh there will clearly exist ownership of a handle to the MeshAllocator VS the only proof that RenderMesh owns vertex data being in mesh_allocator.rs

Also currently the RenderAsset::unload_asset, which I would use to manually free claimed resources, would need to change from being called "whenever SourceAsset is removed from the MainWorld" => "Whenever this Asset is Dropped" (Aka Source Removed OR Changed/Reprepared). This would allow us to reclaim resources in that step. Also we would need to pass self or &self into the function so it can use the handles to reclaim resources.

[larsraph]

Looking at MeshAllocator I think the reason behind it's current design is to allow batching the freeing/allocating of the underlying Buffer resources by doing a prepass that sums the changes before applying writes.

If this is the case we cannot really just move the allocation to RenderAsset::prepare_asset which acts like each RenderAsset is independent.

There are a few possiblities:

1. Keep using the key mapping
2. Extend RenderAsset methods to be able to do a prepass step (w/o compromising base functionality)
3. Make a new public trait like BatchedRenderAsset that supports a prepass step
4. Manually impliment the RenderAsset prepare_asset function (current whats happening)

Besides that this issue has two points that are sorta irrelevant to the main issue

1. I think that RenderAsset::unload_asset should be called in a different context. I'll make a separate issue for this.
2. I want to mess around with MeshAllocator internals because I think I can improve them.