Dynamically load systems

[nixpulvis]

Right now we only load systems on a dedicated Searched event. The correct architecture is different.

• Program loads, window spawns, Startup is called a. Load GUI b. Spawn camera at origin with reasonable zoom level c. Start loading systems in background
• Loading systems a. Start a search for the current camera's view frustrum b. Start a search for the neighboring regions of space
• As the camera moves a. If it is close enough to the edge of the loaded neighbors, load more neighbors b. If it is outside a loaded region, start a search for the current camera's frustrum

This should achive cleaner separation of user events and star system loading. We can think of the camera as what drives the loading of systems. Simply moving the camera to a new position should automatically start loading the correct set of stars once their Bvy systems are running.

It's unclear to me right now if we should have two systems, one for loading the camera's view and one for loading the out of view neighbors. Or if a single system is all we want, where it first loads the camera view, then goes off and loads the neighbors.

[nixpulvis]

https://bevy-cheatbook.github.io/fundamentals/async-compute.html

[nixpulvis]

I'm not going to update the description, but the UI loading order isn't necessarily correct. That's fine, and not the point of this issue.

[nixpulvis]

By c7ebdbdf3fbb73c52bfec7f55463ad8c1164077e we have pretty good dynamic loading. Could be much better.

Next up:

• [x] Support routing
• [x] Support faction search
• [x] Ability to toggle system entity despawning
• [x] Ability to change search radius

[nixpulvis]

MVP faction search 5ede60403bb36c461945ebd04580c46de40abed8

[nixpulvis]

MVP routing 1fb2530338a16db57921c26ad87be1dfba2d39a5

[nixpulvis]

MVP toggle 51af3debfbb0e7da298fac57bbb91dad616a81ee

[nixpulvis]

MVP spyglass radius 2a26ee308d36d322e978c74d89ddb2bed4f1a9fc

[nixpulvis]

Pretty happy with this now. I should open a PR and review it.