Remove the need for config file names to be semantic

[atruskie]

Is your feature request related to a problem? Please describe.

We originally added semantic meaning to config file names when we added support for strongly typed configuration files.
This change was needed because to deserailize a file of type X one must know the type of X before hand - that information must come from somewhere. The three options we have are:

1. A parameter on the command line (not very ergonomic, but it is explicit)
2. Some sentinel value in the filename of the config (the current solution)
3. A value from withing the config file (the old solution)

The old solution was removed because to read a value from the config file, you have to read it once in an unstructured/weakly typed format and then read it again in a strong format - this is complex and inefficient.

The problem here is that filenames with semantics make it harder for our users to understand what is going on, and with the advent of generic recognisers, where we no longer have a 1:1 relationship of config files to config classes, the current solution is less ergonomic.

Describe the solution you'd like

We want to go back to reading the value from the config file. I believe we can break the serialization steps up into distinct steps which will allow us to process the config file in stages - which will be more efficient than doing a whole file read twice.

Describe alternatives you've considered

Alternatives listed above.

Additional context

More of a concern because of generic reocgnisers.