[Audio] Lavalink Plugin Support (mainly spotify + apple music)

### What component of Red (cog, command, API) would you like to see improvements on?

Audio

### Describe the enhancement you're suggesting.

Lavalink has released a new plugin API, which allows developers to create extensions without needing to fork and recompile the entire project. Some things people have made with this API is a [SponsorBlock](https://sponsor.ajay.app/) [extension](https://github.com/Topis-Lavalink-Plugins/Sponsorblock-Plugin), which for those who don't know what that is, allows sponsor segments that are embedded into the video to be automatically skipped, and a [Apple Music and Spotify extension](https://github.com/Topis-Lavalink-Plugins/Topis-Source-Managers-Plugin) which allows music to be played from those sources via looking up the metadata (not direct play)

Currently, Red's Spotify support uses the YouTube API which in most cases (ignoring caching), only allows 100 track lookups a day which can be a problem for people trying to play larger playlists.

Using a lavalink plugin, we would be able to overcome the 100 track/day limit because instead of spamming youtube with a bunch of requests at once, it resolves the tracks to youtube (or whatever else is specified in the config) urls at playback since using lavalink's /loadtracks all at once would get a 429 very quick for users with a single IPV4 address.

I have created a [branch of Red](https://github.com/kaogurai/red/tree/remove-spotify) that removes all Spotify logic (besides a tiny bit in the Query class), as all of it will be handed off to the plugin. It's not PR ready yet, but I've been running it on my bot for while now and it's been running fine.

This does, however have some possible downsides:

For one, in my branch I have removed the `[p]genre` command as it uses raw Spotify API requests, but it would be possible to reimplement this command in a different way if people think it would be worth it to do so.

Since lavalink looks up all tracks on playback, Red has nothing to do with it, and Red's lavalink cache is not used. I haven't done any testing to see if there's any difference of how long it will take to get IP banned by youtube this way, but it's worth looking into this.

At this time on my branch, Red caches the /loadtracks response from lavalink, which includes the contents of a playlist. This does speed up how long it takes for the playlist to load (even without caching, it's MUCH faster than currently), but if a user was to add a new song to a playlist, it would not update until Red clears the lavalink cache, which may be a while. However, this is the current behavior for YouTube playlists so I'm not sure what to do here

### Anything else?

_No response_