Implement sparse morph settings, compute health/speed when not provided

[asanetargoss]

Hello, there! This is the probably the largest major pull request based on a subset of current Changeling's differences from Metamorph. Its main focus is an overhaul of the settings system to support "sparse" morph settings. This is done in a way that shouldn't break add-ons that depend on Metamorph.

From a user's perspective, the main difference is that health and speed are calculated automatically for entity-based morphs that have not been configured yet. This allows for a better morphing experience by default, and makes it less tedious to customize morphs. Some morph speeds may not be calculated correctly, but it should work for most modded mobs that are based on vanilla mobs.

From a technical perspective, sparse morph settings allows for incremental configuration of morphs over time. This has the following impact on the Metamorph code:

• Each setting now has a "defined" flag, which is true by default. If the defined flag for a setting is set to false, it may be overridden. This can happen when loading morph settings from morphs.json
• The global default settings for a morph are now stored in MorphSettings.DEFAULT_MORPHED
• The global default settings for an unmorphed player are stored in MorphSettings.DEFAULT
• The new function AbstractMorph.getSettings() initializes the morph's settings if needed. It's now the recommended way to get settings for a morph.
• The lifecycle of a morph setting is more robust: In certain cases, rather than making in-place modifications to a single settings object, different settings objects are composed together. There is now no ambiguity on whether a field in MorphSettings is defined or not, and defaults can be changed if needed.
• Health and speed are now auto-computed for EntityMorphs when the respective field in MorphSettings is marked as not defined. The speed calculation in particular is not perfect, as it uses a heuristic, so some morph settings may still require setting the speed for a morph.

[Chryfi]

Thank you, I will review as soon as I have time again.

[asanetargoss]

One additional detail regarding the current implementation as of this commit: hasAbilities, hasAttack, etc have been made true by default for theoretical backwards compatibility reasons, i.e. an addon initializing a MorphSettings object for some purpose.

If we want to discourage the use of hasAbilities and the others, due to future refactoring, I can mark them as @Deprecated