Fix substitutions in files included from within a list

[rynonl]

fixes #160

Allows for substitions/includes from within a list, and also allows += inside a list.

Regarding the test at ConcatenationTest:355 - This syntax is not specified as valid per the spec(at least not that I could tell) leading me to believe this is more like undefined behavior than related to the +=/includes within a list. I left the test in but with the exception that now gets thrown.

[havocp]

Thanks for working on this!

I believe with this patch, if someone uses ${foo.0} in their config file, we would look up element 0 in the list foo, so we've added a new behavior that would need to be described in HOCON.md and also thought through in terms of implications. It may actually make sense - because we do let you treat a numerically-keyed object as an array, treating an array as a numerically-indexed object might be fine. But I hadn't thought of this solution before and so I need to think about it. It's important to "prove" to ourselves that nobody could be using the ${foo.0} to mean something else already in this case, so we know we won't break anyone with this.

[havocp]

If we want this to be invalid syntax, we should be throwing the Parse exception or a resolve-related exception, not the BugOrBroken.

I don't understand why it's invalid though; it expands to something like this right:

 x = ${?x} [ { a = ${?a} [1], a = ${?a} [2], a = ${?a} [3] } ]

It seems logical to me - the only "twist" here is that we have two nested lists, right? Or am I missing something?

The resolve code is definitely "fun" but it's probably possible to fix this.

[havocp]

oops, I got the expansion wrong - should be something like a = ${?x.0.a} [1] etc. right?

[rynonl]

Added some information about indexing semantics for includes within lists to Hocon.md

As far as proving to ourselves that we won't break anyone...I can't think of a scenario where this would. If people are using ints as object keys now it should just continue chugging along because this patch explicitly looks for lists before appending indices to the path. You would know better than me about any edge cases though :)

I see what you mean regarding the += being valid syntax, however I think that is a separate issue than including from within lists. thoughts?