refactor: race_director: using bevy_ecs as a basis (WIP)

[theangryangel]

What

This adds a very WIP implementation of using bevy_ecs as the fundamental basis for race_director.

It’ll be a very slow burn over the next few weeks.

It will start by

• [x] dropping support down to a single server, during refactor
• [ ] add support for basic insim integration
• [ ] add support for publishing insim packets as bevy Event’s
• [ ] then we’ll work on basic “plugins” like track rotation, XP, etc.
• [ ] scripting support
• [ ] then we’ll work on persistence to a database
• [ ] then we’ll work on web server integration for things like a livemap
• [ ] then we’ll re-add multi-server support

Thought process

I have chosen not to use the bevy and/or bevy_app base crates because:

1. We dont need anything bar the ecs, and a few helper methods
2. A few features like Plugins we have slightly needs and can go more bespoke (direct config file integration, for example)
3. We want tighter control over how and when the schedules run
4. We probably want our own schedules, and the way the plugin trait currently works its “fork or suck it up” territory

Context

Over Christmas I had a bit of time to fiddle with writing a “scene” system for race_director.

The more time I worked on it the more and more it started looking like a hobbled ECS:

• I wanted the ability to have removable “scenes”
• I wanted the ability for each “scene” to have it’s own data, but still pull from a basic game state
• I wanted the ability to turn “scenes” on and off based on the state of the game
• I was starting to have data ownership issues and throwing Arc at everything just to get a minimally viable version up and working
• I was looking at resurrecting the IndexMultiMap implementation from git history

[theangryangel]

Moved to theangryangel/race_directord.