Return/log an error when attempting to load an empty asset path.

[andriyDev]

Objective

• Partially addresses https://discord.com/channels/691052431525675048/749332104487108618/1489425547598762095
  • Currently BSN will attempt to load a string whenever a handle is seen. Unfortunately, BSN treats nothing to mean the empty string. The asset system then tries to load the empty string and returns various unhelpful error messages depending on your OS.
  • This doesn't totally fix the issue - BSN should probably not be loading these paths at all. But more generally the asset system should just ignore empty paths entirely since it should never load a meaningful path.

Solution

• In every load variant, add a check for the empty path and log an error or return an error in that case. We also return a default handle in that case (where necessary).
• Intentionally don't handle load_folder. You could theoretically want to load the root folder!

To address some alternative implementations:

• There isn't a common loading API that all roads lead to! Each one is a little different, so we need to handle them in each case. We should investigate collapsing some of these though.
• AssetPath still needs to be allowed to parse an empty path, since for stuff like joining asset paths, that needs to support cases like "only a subasset label", or "joining the empty path with some subdir path".

Testing

• Added a test to test all the load variants on AssetServer.

[greeble-dev]

Looks good. I would tweak the message slightly - "Attempting to load an asset with an empty path" seems just a bit clearer - but it's not a big deal.

There's a few places that might be missing checks?

• AssetServer::reload/reload_internal.
• LoadContext::read_asset_bytes.
• Maybe ProcessContext::load_source_asset - not sure about that case.

[andriyDev]

@greeble-dev

• AssetServer::reload/reload_internal should be ok since it should just find no handles to reload and no dependencies on that path (since a dependency also requires a valid load), so it should do nothing. We could do it as a fast check for optimization? I don't care about this though - I'd rather it just be handled by the existing code.
• ProcessContext::load_source_asset doesn't need it since we don't give it a path at all. The path is deduced based on which asset in your source assets is being processed. So this will always load a good path. Though, we should really allow ProcessContext to read any unprocessed asset - then we would want to add this check!