Refactor the settings code to allow incremental updates and protected keys

Description

Refactor the settings code to allow incremental updates and protected keys. The old settings code was horrendous, even server-side. For example, this is how setting updates from the API were applied to the current instance:

1. parse the request from JSON
2. serialize to JSON
3. write to disk
4. read from disk
5. parse JSON
6. replace the GlobalSettings instance

It should be clear that a refactor was very much needed!

Changes

• Settings received at the /api/v1/settings endpoint now upsert only the keys contained in the request. Previously it would generate a new GlobalSettings instance and populate the partial settings, leaving the rest at their defaults
• Improved way numbers can be requested from the settings object. Previously it was a bunch of ifs-else-ifs, now it's a map of mapping functions with the default being the identity function. This also adds support for cross-type requests (getting a float from what's actually an int, for example) and adds support for actual floats instead of just doubles.
• Entirely revamped the way settings are loaded and stored. Now it makes sense

Additions

• A type mapper for TimeUnits, which occurred enough throughout the codebase that it warranted such integration
• A way to change the location of the configuration file, in theory. The path of the file is stored in the settings itself, so with a way to specify this from the command line the location could be changed when starting the core. This requires additional code though.

Test and Review

To be filled in by the reviewers

• All of the methods are commented to expectation

• The methods are tested to satisfaction

• There are no unnecessary files present in the MR

• The continuous integration has no problems with the MR

• The MR is filled in as requested (including labels, milestones, and reviewers)

• The documentation is up-to-date

• All nullable parameters are marked as such