Make asset loading no longer use the type of the load.

[andriyDev]

Objective

Fix a bunch of weird edge cases of asset loading:

• Currently when loading an asset, we use the type of the handle to decide which loader to use, and if that is ambiguous, we fall back to using the extension.
  • So for example, if we call asset_server.load<Gltf>("whatever.png"), this will try to use the GltfLoader since we prioritize the asset type not the extension.
• We're able to load the same asset path multiple times provided that you use different asset types.
  • For example, if you call asset_server.load<Image>("whatever.png") and asset_server.load<Gltf>("whatever.png"), this will actually do two loads, even though one of these loads makes no sense!
• Untyped loads can't be deduped.
  • Even if we see a load happening for a specific path, we don't know whether that load is the right type, so we have to fully do the load just to then find out that the type of the asset we loaded was wrong.

Solution

• We no longer pass the type when finding the loader. This significantly simplifies the loader selection.
• This means that loading a path is now totally unambiguous allowing for future simplificaftions.

I haven't fixed all of the above issues, but this is the first step.

Testing

• None. This is pretty much a delete.

[beicause]

Why shouldn't it be allowed to load an extension as different types? For example, a custom asset loader could load a png as a custom type different from Image. ron is also a example. If removing the type selection, you have to duplicate the same file.

[andriyDev]

@beicause loading an extension as multiple different types breaks a lot of things. For example if you are loading several types from the ron extension, untyped loads are entirely broken, since we don't know which ron loader to use. The migration guide already has two alternative ways to fix this.

Here's a third, specifically for Ron loaders (or other containers like JSON). Instead of having one RON loader per type, you just have one ungeneric RonLoader, which returns a struct RonContents(UntypedHandle);. The handle will store a subasset which holds your real asset contents. Then users just do something like asset_server.load::<MySpecialType>("blah.ron#Typed"). This would of course mean that inside your ron file it needs to record which type to load as (which most don't do today).

The point is there are workarounds, and that we end up making the asset loader totally unambiguous. That fixes untyped loads, editor workflows, asset processing, and more. Relying on guessing the correct loader based on how you load it falls apart whenever you're not loading it yourself, and I think it's a good thing to make the assets on disk "self-describing".