[Major release] Spicetify v3

V3 comes with a major architectural shift, with goals of correctness and robustness.

📝 Provide a description of the new feature

V3 splits the project into a CLI/TUI, hooks, and modules:

• The CLI will have built-in support for installing modules from GitHub URLs, a URI handler, and a daemon service. The CLI will only be responsible for extracting xpui.spa, setting up symlinks from xpui to spicetify's config folder, and patching index.html to load the hooks. The CLI is as minimally intrusive as possible.

• The hooks are the first javascript that runs on the client, they mainly patch the webpack loading mechanism to allow runtime injections and transformations on the source files. They're also responsible for loading the modules after ensuring that all their versioned dependencies are met and have been loaded.

The CLI and the hooks are assumed to be universal, they should work on all Spotify versions.

• Modules are the generalization of jsWrappers, extensions, themes, custom apps, and snippets. Every module has a metadata.json, containing information about the module and entry points for js, css, and mixins. Modules are identified by a string, and can "depend" on (version ranges of) other modules.

Modules can also "depend" on specific version ranges of Spotify itself.
Modules (including custom apps) have a lifecycle and can be loaded and unloaded without refreshing the page.

Start by mapping the proposed CLI/TUI, hooks, and modules boundaries described in the issue, including the CLI responsibilities and the hooks' loading flow. Done would require an agreed and implemented V3 architecture covering module metadata, dependencies, lifecycle, and Spotify version compatibility; no files or tests are named.