Shifts the contents of `kvui.py`, and thus all CommonClient-based clients as well as Launcher, to using KivyMD. KivyMD is an extension for Kivy that is almost fully compatible with pre-existing Kivy components, while providing Material Design support for theming and overall visual design as well as useful pre-existing built in components such as Snackbars, Tooltips, and a built-in File Manager (not currently being used).
As a part of this shift, the launcher was completely overhauled, adding the ability to filter the list of components down to each type of component, the ability to define favorite components and filter to them, and add shortcuts for launcher components to the desktop. An optional description field was added to Component for display within the new launcher.
The theme (Light/Dark) and primary palette have also been exposed to users via client/user.kv.
* Expand and validate the RAM cache
* Part way through location improvement
* Fixed location tracking
* Preliminary entrance tracking support
* Actually send entrance messages
* Store found entrances on the server
* Bit of cleanup
* Added rupee count, items linked to checks
* Send Magpie a handshAck
* Got my own version wrong
* Remove the Beta name
* Only send slot_data if there's something in it
* Ask the server for entrance updates
* Small fix to stabilize Link's location when changing rooms
* Oops, server storage is shared between worlds
* Deal with null responses from the server
* Added UNUSED_KEY item
* Added some resilience to non-ASCII player names or items
* Also the client, not even sure if switching to ascii is useful here
* Split a long line in two
There was a bug that randomly after opening and closing the menu, some players on Bizhawk would get old items again. Tracking this down took multiple hours over the course of several weeks. The root cause turned out to be reading from the System Bus domain while an DMA copy was happening. Doing so is undefined behavior on GBC (though I'm sure some game relies on it). On Gambatte, you end up reading some garbage byte no matter what the read is (unsure what the providence of the byte is - some garbage, some register, the actual DMA data, who knows?). Normally, this isn't an issue, as Bizhawk callbacks only happen during vblank/halt, which is generally a state where we have valid WRAM to read from. However - a setting is being passed around the community for Bizhawk that changes the frame counter to go from "only when Vblank happens" to "whenever some number of audio samples have happened" which causes the bizhawk callbacks to happen....nearly whenever. Including during a DMA. You can tell this is happening if you print the `PC` register when reading memory - if it matches `FFXX` then you are executing in a routine in HRAM and likely doing a DMA.
Additionally, the check items counter specifically is in WRAM Bank 1 which could be swapped out of - will have to keep an eye on this - generally LADX lives in Bank 1, but there are a few things that use the other banks (swap space for some objects??). This could be a problem on any platform - if we get more reports of bad items gets, that's probably why.
Also, fixes some logging that was never getting reenabled.
