Property syntax is inconsistent and doesn't work well with alternative sources

[dmlloyd]

Describe the bug

The high-level syntax of a configuration property value depends on a couple of factors right now:

• The converter being used
• The type of configuration source being used

For example, if I have a properties file, and I have a configuration property value foo,bar, this value has different syntax requirements and limitations depending on whether this value is a list or a simple string. Furthermore if I have a YAML-backed configuration source, which already natively supports lists, the source has to "collapse" the value back into a string list again, which makes little sense.

The fact is that our converter rules presently assume that the backing value is always a simple string in a properties-like file, and this is severely limiting for users.

We should impose syntax rules for aggregate types on a per-ConfigSource basis. The ConfigSource should be able to return either an unconverted string, or (if the config source supports it) a native numeric or list value, without having to go through superfluous conversion. This might mean that ConfigSource implementations need access to the target type and/or converter, but this might be a logical consequence of #43 and its successors.

This relates strongly to #545.