Encapsulate configuration

[itowlson]

In the first iterations of Spin, for speed of development, the internal configuration object was a direct representation of the TOML configuration file. As we've seen in projects like WAGI and the Hippo CLI, this tends not to be sustainable: the application code ends up having to repeatedly perform the same validation/massage on the raw deserialised object, and you get alternative config flows that end up being awkwardly crobarred into that first serialisation format because so much app code is coupled to it.

It's hard to predict future configuration needs so this may be premature, but if we can make a reasonable stab at abstracting the configuration surfaced to the application from the raw serialised format, we will hopefully mitigate the effort of transition when it comes.

As an initial stab, I'd suggest:

• Public interface of config crate should be
  • Configuration objects designed around the needs of the application as best we understand them
  • Associated functions for parsing those configuration objects from sources such as files and strings
• Private (hopefully) config::serialisation module that deals with things like the raw on-disk TOML format

Related: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

[itowlson]

This may fall naturally out of the bindling project.