refactor: decouple lyrics providers from synced-lyrics

[Yumeo0]

This splits the actual lyric fetching from the lyrics displaying.

I thought it was logical to split out the lyrics-provider when I worked on the better-fullscreen plugin because fetching the lyrics multiple times seemed stupid. So I create the lyrics-provider plugin and a way for other plugins to depend on it.

This PR also rewrites the synced-lyrics plugin to use the new lyrics-provider.

[ArjixWasTaken]

I am converting this to a draft PR so annoying copilot won't pollute the chat.
I've noticed that you have not documented in the PR the changes you've made.

You introduced a dependency system between plugins, you detect circular dependencies, among other stuff.
Could you spend 30 minutes detailing your design choices, so we can discuss them?

Plus, if we are going to do a refactor of this scale, might as well implement a local lyrics database, to reduce our reliance on the lyrics providers being available. (and avoid rate-limits)

So discussing it first is the way to go

[ArjixWasTaken]

I would be in favour of introducing a dependency injection container for such needs.
My personal favorite is di-wise

[Yumeo0]

Plus, if we are going to do a refactor of this scale, might as well implement a local lyrics database, to reduce our reliance on the lyrics providers being available. (and avoid rate-limits)

I'm gonna comment on everything else later but I just quickly wanted to say that this is absolutely out of scope for what this PR is supposed to do. I only copy pastes the code from synced-lyrics into the new plugin. I didn't change the underlying logic at all. If somebody wants to add a local lyrics database in a new PR they can feel free to do so.

[ArjixWasTaken]

I'm gonna comment on everything else later but I just quickly wanted to say that this is absolutely out of scope for what this PR is supposed to do.

I may have been too ambiguous, by "database" I meant having a local .json file or smth that "caches" the lyrics across app restarts.

Currently we store them in memory, and only keep them cached for the lifetime of the session.

const searchCache = new Map<VideoId, SearchCache>();

[Yumeo0]

You introduced a dependency system between plugins, you detect circular dependencies, among other stuff. Could you spend 30 minutes detailing your design choices, so we can discuss them?

Topological Sort
I had to make sure that the dependencies load before the dependents so I implemented a depth-first topological sort with cycle detection that I found online.

const topologicalSort = (plugins) => {
  const visiting = new Set();  // Tracks current DFS path (cycle detection)
  const visited = new Set();   // Tracks fully processed nodes
  // ...
}

The visiting set detects circular dependencies—if a node is encountered while still in the current DFS path, it's a cycle. This prevents infinite loops and warns the developer.

Global API exposure via window
I just put the API object onto the window as I thought this was a simple enough use-case seeing as the dependencies always load before the dependents which means it is always available. I can look into dependency injectors though.

Providing the lyrics
I just used a simple solid store to create a reactive store which other plugins can consume. Should be pretty self explanatory why it is that way.