Separate Schema from Config

[LswaN58]

Separating "Schema" from "Config"

Problem

Currently, we've got a weird mixing of configuration and documentation in our Schema classes.
A great example of this is our current "game schemas." These contain both the configuration of feature extractors (what is enabled/disabled, how many levels/quizzes/whatever are in the game, etc.), and the documentation of what events exist for the game. This is particularly egregious because both parts are in the same "schema." A less-severe example would be the way that our old GameSourceSchema would contain configuration information (e.g. which table to use), and have a link to a TableSchema, which effectively just documents/defines the mapping of column names to table columns.

Proposed Solution

configs Module

This proposal is effectively just a major renaming effort, with very little in the way of functional changes. We simply need to be explicit about the difference between "configuration" and "documentation."
Essentially, we'll just create a "configs" module, with a Config base class that is just a thin wrapper around the Schema base class.

configs and schemas Module Restructuring

The classes currently under schemas will be reorganized to move config-related schemas out to the configs module. These will all be renamed to have their suffix changed to Config, e.g. TableConfig instead of TableSchema.

The following submodules should become "configs" instead of "schemas":

• configs (duh)
• from games: FeatureSchema, DetectorSchema, and subclasses; FeatureMapSchema and DetectorMapSchema.
• storage (containing DataStoreSchema and similar)
• from tables: TableSchema (the new one; TableStructureSchema can return to TableSchema, similar for subclasses)

[LswaN58]

This proposal was implemented in #67