Implement Load Progress Tracking

[zicklag]

Loading screen still needs to be implemented.

This PR implements a solution for tracking the load progress of game assets.

This works towards #161, but it doesn't implement the UI yet, just the load progress tracking.

It allows us to get the load progress for both GameMeta and LevelMeta and adds logic to wait until game and level assets are loaded before starting the game/level. This time period should be replaced with a loading screen in a subsequent PR.

Why This is So Complicated

Tracking the loading progress for the game is not trivial due to the fact that we have several different kinds of asset and handles referenced throughout the GameMeta struct at many different levels of struct nesting.

My initial thought was to add a simple function where I simply manually return all the HandleIds in the various different parts of the GameMeta struct in a vector. This instantly became very difficult because of how spread out between types the handles are. There wasn't a good way to know if I had gotten all the handles, and if we added more handles later, we would have to remember to update the list which would be horrible to manage and would almost surely become out of date.

Instead, in this PR I added a HasLoadProgress trait that we use a custom derive macro to derive on GameMeta and all of the structs that it contains. This ensures that all of the handles contained in the GameMeta struct will be properly evaluated when checking load progress and it doesn't require difficult manual listing of handles.

The cost is that we write a macro and add a macro crate to our codebase, but this took me less than a day, and it is a relatively simple macro. I think it turned out rather elegant and I don't know of any other reasonable alternative at this point, but let me know if you have other thoughts!

[zicklag]

After testing on web there are two caveats that mean we still get some initial frame glitching while the page is loading:

1. On the main menu, the menu frame appears off to the side in a weird spot for one frame. This has to do with the way that egui centers the frame, and isn't really related to our code otherwise. Maybe we should just do a fade in from the loading screen once we have it to allow time for the frame to center. Anyway, not a huge deal for now.
2. Because of the way bevy_parallax_background is setup, we don't have access to the handles it uses for the background, and can't tell if it's loaded yet. 🤔 I might be able to fix that by loading handles into the level asset. I'll check that out.

[zicklag]

OK I fixed the parallax background issue by loading the background image handles into the LevelMeta struct so that we can check on their load progress too.

As far as the egui menu issue, I think we tackle that later as it's really a minor point for now, though definitely something to look into later.

[64kramsystem]

Nice! 👍

[zicklag]

This should be ready, but I'd like your buy off at least on the idea of adding a macro crate @odecay before we merge.

[odecay]

Ah what happened here? I haven't had the chance to look it over and now see its closed.

[zicklag]

I'm in the middle of re-basing it, but I'm not sure why it automatically closed?

Give me a second.

[zicklag]

There pushed the rebase.

[odecay]

I'm not conceptually opposed to the idea of having macro crate. I've not written macros before but I looked over the macro code and it doesn't seem too bad.

[zicklag]

OK, then I'll merge this and as always we can change/improve later!

bors r+

[bors]

Build succeeded:

• Check Rust formatting
• Clippy correctness checks