Define a structure for configuration definitions

[A248]

This issue may seem obscure in essence, but it is a backbone for adding more flexibility to DazzleConf in several areas, such as #37, #30, #35.

A configuration definition is the result of reading a config interface and determining its required methods, their return types, default values if present (or if required, see #36); effectively, it is the whole structure of a configuration. It should also include mapped keys (#38).

We can define a configuration definition provider as the interface responsible for creating configuration definitions. When a configuration definition is made, I also propose that the relevant serializer is attached to the definition at the key, rather than retained globally and looked up as required; this would allow wildcard serializers as mentioned in #39.

Here is an example putting this all together:

Configuration<MyConfig> configuration = Configuration
  .builder() // Or builderWithoutDefaultSerializers
  .withSerializers(...) // ValueSerializer... or Collection<ValueSerializer>
  .keyMapping(new DefaultKeyMapper()) // Can be omitted
  .definitionProvider(new DefaultDefinitionProvider<>(MyConfig.class))
  .instantiator(new DefaultInstantiator()) // Not generic over MyConfig. 
  .migrations()
  .backend(new SnakeYamlBackend(
    new ConfigurationFile(path) // Provides methods such as newReader, newWriter, and buffered variants
    // Can also provide options here
  ))
  .build(); // Throws IllDefinedConfigException if developer error

// ConfigResult returns elements such as auxiliary keys, whether defaults were written back, migrations performed, etc.
ConfigResult<MyConfig> myConfigResult = configuration.reload();
MyConfig myConfig = myConfigResult.loadedValue();

// Can build out further abstractions related to reloading
Reloadable<MyConfig> reloadable = Reloadable.create(configuration);
reloadable.setBackingInstance(myConfig);
assert reloadable.getBackingInstance() == myConfig;
MyConfig reloadProofConfig = reloadable.getTransparentProvider();

We can use multiple builder steps so that adding the definition provider and instantiator can be done in an ergonomic generics-friendly fashion. The definition provider should be composable so that the configuration is modular: that is, combining non-overlapping configuration definitions must be possible. Loading by multiple files would also be possible by wrapping the backend. The backend in this design proposal, unlike in the current library, is stateless and decoupled from other aspects of DazzleConf.