Schema/Config Loading and Defaults

[LswaN58]

Schema/Config Loading and Defaults

Currently, we have a Default function for all subclasses of the Schema base class, to ensure there is always some fallback when a schema can not be located at load-time.
However, these are typically just using vague "NOT FOUND" values or similar, instead of real, useful defaults as encoded in the *.template files that exist for certain configs in ogd-core and other repos.
Additionally, it is assumed that the user of the class(es) knows an exact, single directory where the config or schema exists, and thus doesn't really have a capacity to handle configs on e.g. a package installation.

Smarter Loading

Each top-level schema/config should have a Load function, which takes a filename and search directory, and implements the following logic:

1. Look for given file in given directory, if found, return
2. Look for given file in working directory, if found, return
3. Look for given file in platform-specific config directory, if found, return
4. Repeat 1-3 for each filename in a list of default file names (including *.template files), if any; if found, return
5. Return the class default

Loadable Schemas

Currently, the only general groupings within the Schema inheritance tree is the distinction of Schema vs. Config, which really just refers to the role the data plays, rather than any distinction in the functionality of the classes.
However, with respect to the loading functionality, there is more of a focused distinction, between top-level Schema subclasses, and lower-level subclasses that are just aggregated into the top-level subclasses.
The top-level subclasses should have the Load function, while lower-level ones don't have a use for it.

Generally speaking, the top-level schemas/configs are:

• Program-level configuration, in ogd-core that is currently called ConfigSchema. Hasn't yet been updated based on the schema/config split.
• Game-level configuration, currently a part of GameSchema, but should be split into feature+detector configuration
• Game-level documentation, currently a part of GameSchema, which should be split into event schema documentation
• Table-level documentation, the TableSchema class.