Refactor metadata lookup flows

[bdach]

RFC. Probably wouldn't recommend merging into any hotfix releases if anything of the sort is coming soon.

This precedes a fix to a bug in the metadata lookup flow I found a while back, loosely described in footnote 1 here. There are two reasons why I went off on this detour:

• Currently BeatmapUpdaterMetadataLookup has the logic of applying the metadata of the map duplicated in two places (depending on whether API or the local metadata snapshot is being used), and I would have had to fix up both places as both are susceptible to the same bug that I want to fix. I find that kinda weird as the two places are doing precisely the same thing, based on the same type of data, which is just sourced from a different place. So this restructure kind of logically made sense to me.
• After working with this code a while, it turns out that there are a lot of undocumented and not-obvious expectations from the metadata lookup flow which are currently not exercised by tests in any way. I wanted to get this code under a test harness before I started working it further, to make sure I don't accidentally break anything along the way.

All of the above is mostly argumentative and subjective, and none of it is strictly necessary for fixing the bug that I want to fix, but I kind of like the end result. So I want to see what the reaction to this will be.

[peppy]

This took a bit to get through. But coming with a fresh look on the structure of these classes, I think I can agree that I like the end result.

One thing I'll mention is that I think there might need to be an end goal of using the local cache more frequently, or adjusting the throughput of api requests as this api fetch process is the main blocker of import speed. That is obviously something that can come as a follow-up later on.

@bdach I hope you still have the aforementioned bug fix branch sitting around to follow up with 😅