How much of Hocon should we support

[rogeralsing]

I've been looking into the Hocon spec a bit more and some of the stuff in there are just crazy.

We do support substitutions already, but according to the Hocon spec, substitutions should be able to self reference

a : some value
a : {$a} and some more
a : {$a} and even more

In the above case the result should be "some value and some more and even more"
There is some conflicting info in the spec saying that substitutions should be done at the end, after all files have been included and parsed.
Which means that somehow, the parser result should remember all three of those lines.

The next part is includes.

a : { x : 123 }
a : { include 'somefile.bar' }

In the above case, the contents of somefile.bar should be merged with the existing value of a, which means that we probably have to load the other files during parsing, and prepend the result onto the string that is being parsed.

And to combine the two into a joy of brain pain.
somefile.bar can contain substitutions that ar relative to the document itself when loaded, but once inserted into the including config, the paths should be rewritten relative to the place where they are inserted into the inserting config.

I really don't want to change the parser to some multi pass parser that does the same'ish thing over and over untill the final config is produced.

So which of these features do we need? should we just let this be for the moment?

[rogeralsing]

I've actually got some progress on this, we can resolve includes, and fixup substitutions in includes.
Not sure what to do with the self ref substitutions though.

The include resolver is a Func<string, HoconRoot> which we can optionally pass to the ConfiguratonFactory.ParseString, we can use this to resolve external configs as long as we return a hocon object back.

I also realized that since Hocon is a superset of json, we can serialize .NET objects to json, and then parse the json as hocon.
Which allows us to create typed objects that can be turned into config objects with a single method call.

So this will probably open up for some nice use cases

[rogeralsing]

This has been merged.
Will open up a separate issue if we ever think we need self referencing substitutions.