Feature: External (mod-provided) data layers

[focustense]

Adds an API for other mods to register and implement their own data layers.

The API has a single Register method which takes an IDataLayer. That, in turn, provides the legend data, colors, translations, update logic, etc.

Externally-registered layers act just like internal ones; they show up in the GMCM and the UI widget as if they were normal layers.

There might be a few caveats or rough edges here; in particular:

• The ColorScheme is entirely internal to Data Layers. Users of a mod that is based IDataLayersApi probably won't have anything set up in their color scheme for that mod. I'm not sure how useful it really is to bother with color schemes in this context, but if a user adds those keys to the colors.json then it should work normally.
• Internally, LegendEntry has a convenient constructor that allows omitting the name if I18n key is used as ID. This doesn't work when going across the API boundary, because DataLayers only sees its own translations, whereas the registering mod would be providing a key for itself. This means mods have to provide layer names as well.
• By default, newly-added configurations are set to update 60 times per second. This default is in DataLayers itself, and makes sense when DataLayers is providing its own explicit defaults per "mod integration". However, if external registrations default to 60x and users don't change it (most won't) then it will suck up a lot of performance. Should we consider changing the default in DataLayers, or using a different default for layers added through the API?

There's an example consumer in 078a47d.

[focustense]

I just noticed that this got closed - GitHub apparently didn't see fit to notify me about that.

I force-pushed because GitHub made an awful mess of everything when I tried to sync, insisting on doing everything with an entire month of merge commits instead of a simple rebase. So I locally deleted the branch, rebased properly and force-pushed a new branch assuming that GitHub would update the PR. It didn't; instead it just... gave up, and closed the PR.

Anyway, there's a new PR with identical commits at #1020, for whenever you get back to mods and are ready to review/merge.