[Tech] Make LibraryManagers and GameManagers actual classes

[CommandMC]

Note

Do not be alarmed by the huge amount of changed lines in this PR. Most of it is whitespace changes (since indentation changes from 2 to 4 spaces). The main changes in this PR are in bb0a140, whitespace changes are in a927d23 (so ignore that one)

Library & game managers were long used as pseudo-classes (having a defined structure & being used like a class instance, but not actually being a class). This causes various issues:

• changing a manager file does not track object shape properly (there's nothing directly stopping you from renaming a "method" of one of the managers, you'll only get indirect type errors)
• "method" usages are not tracked properly
• manager state is not encapsulated
  • This is admittedly still an issue now, but at least it's now possible to resolve
• when adding a new manager, it's unclear which methods are actually required. Again, you only get indirect errors in the gameManagerMap/libraryManagerMap declaration (or worse, in some other file expecting some extra method), there's nothing pointing you to the error in the specific manager implementation

I am looking to make core changes to the game & library managers (mainly getting rid of or at least significantly slimming down the GameInfo interface) to make it easier to implement more store providers. This PR is the first step towards that

I did make one "functional" change here: I've removed a test file for Legendary's save sync folder computation. I don't think this was working correctly (the test was too specialized, it might've helped more now that the helper binary stubs are in), and I want to change how save sync folders work soon anyways

---

Use the following Checklist if you have changed something on the Backend or Frontend:

• Tested the feature and it's working on a current and clean install.
• Tested the main App features and they are still working on a current and clean install. (Login, Install, Play, Uninstall, Move games, etc.)
• Created / Updated Tests (If necessary)
• Created / Updated documentation (If necessary)

[CommandMC]

Seems like the diff isn't great even with "Hide whitespace" turned on. I'll see if I can split those changes out into (1) code changes and (2) linting

[arielj]

I wonder if we can export each manager too, not just the hash, then we can import legendaryLibraryManager to not have to import the hash and access with a hardcoded 'legendary' string, it would make the code more declarative and easier to understand in my opinion (I know it's a small difference, but I think it will help since it's used so much throughout the app, there's many places we just have hardcoded runners)

[CommandMC]

I agree that this would be a good idea for now. I do have a concern: I'd like to eventually get rid of every one of these hardcoded runner-specific library manager invocations (my end goal is to dynamically enable/disable library integrations at runtime; to load them as "plugins"). Obviously exporting individual library managers would go against that goal
So, I can definitely do this for now (and if you'd like me to, I would). I just don't see it as that much of a problem right now, and given these areas will change relatively soon-ish anyways (I have a draft of this plugins idea around already) I hadn't bothered to change it yet