[DRAFT]: Maxima Server

[battledash]

This is the start of a major refactor of Maxima. The high-level purpose is to allow for multiple frontends to co-exist, so you can, for example, run the TUI and the UI at the same time, and their states will be synced. If you start a game through the TUI, and the UI is open, the UI should display that. This also fixes the dilemma of "if you launch a game through a third-party, which frontend is opened?"

This is being achieved by moving all of Maxima's logic into a separate server process, and turning maxima_lib into a very thin client. The library will start (and download, if necessary) the server. Ideally we would embed the server binary in the library on build, but I don't think crates.io allows for that. The server will shut down if no clients are connected to it for a TBD amount of time. On Windows the server will live inside the win service, which will fix the issue of not having access to Program Files when downloading games.

To start with, I've moved everything into a new crates folder, and renamed the crates to use snake_case instead of kebab-case. maxima-lib has been entirely moved into the new maxima_server crate, and maxima_proto has been created.

Proto is the glue between the library and server. It contains the low-level RPC system, as well as the types that pass between the lib/server. It's almost feature-complete, except for server->client notification support. The RPCs are broken up into "components", which are declared like so:

proto_component!(
    Utilities;

    errors {
        #[error("Incompatible Server Version")]
        IncompatibleVersion,
    }

    rpc {
        identify(IdentificationRequest): IdentificationResponse,
    }
);

maxima_lib is now empty, but will be a higher-level abstraction of the proto requests/notifications, as well as server bootstrapping.

The decoupling of Maxima's logic from the way you interface with it will also allow us to rethink a lot of questionable design decisions which stemmed from a need for a concise API.