Application refactor

[toasted-nutbread]

I mentioned that I was wanting to do this in a comment somewhere, but this change makes the initialization process a bit less spaghetti. yomitan is no longer a global, and instead an Application instance is passed around to the components that need it.

[github-actions]

✔️ No visual differences introduced by this PR.

View Playwright Report (note: open the "playwright-report" artifact)

[toasted-nutbread]

Something this change makes more obvious is situations where there are implicit dependencies that are easy to miss stubbing for tests. For example, AnkiNoteBuilder has a partial dependency on API, which was previously accessed via yomitan. Now all of the potential situations where this would be used don't actually have test cases at this time, but they could. So there is now a MinimalApi class which stubs it. For now this is empty, but it can be populated later if the need arises.

[djahandarie]

LGTM. I sort of feel like "application" (or "yomitan" previously) is not really a valid unit of abstraction / grouping, it should probably be split up a bit differently. But this is just a hot take, haven't really thought about if there is some salient division of stuff in there, or a less-generic sounding category name.

[djahandarie]

(Merge conflict)

[toasted-nutbread]

I didn't name it "Extension" because that is somewhat ambiguous with the overall concept of a "web extension". I went with "application" instead because it's generic and the goal of the class is that it hosts generic components of the class that contain state and are shared around the different parts of the codebase. It kind of serves as an initialization point and an easier way to group a few communication types together (the API stuff).

You're right that it's not a perfect abstraction, and this is reflected by some places being passed api and the likes directly. I'm open to additional suggestions on how to approach this if you feel it's not the right direction. There are a few things that I intend to do that come after this step which should help separate the functionalities handled in the class as it is in this PR, but I didn't want to go overboard making a lot of changes immediately.

The biggest previous design issue that I am trying to address with this is the idea that "yomitan" is not initialized as part of the main function, which makes the dependency map a bit odd. I.e. a lot of things import {yomitan} when they really don't need to, they just need a reference passed to the instance.