Allow integer indexing (closes #92)

[thorio]

This PR contains a few related changes for various issues:

• Indexing arrays in Value::find() (Allow Value::find to traverse arrays #92)
• Providing partial array values from Env (Env provider and array indices as keys #113)
• Necessitated by the Env change, new strategies zipjoin/zipmerge, which allow partially overwriting arrays and values inside arrays.

[amircodota]

@thorio ran a quick test with my use case

Works like a charm for both top level arrays and also arrays in sub-keys 👑

[thorio]

@SergioBenitez could you take a look at this?

[SergioBenitez]

This line is too long. Lines should never exceed 100 characters.

[thorio]

I split the join and merge cases into separate lines, I think this is more readable than any wrapping option.

[SergioBenitez]

Why not make one of the other values a vec![]? The smaller this value is, the easier the example is to parse.

[thorio]

It would involve either the array being fairly deeply nested and/or having an array of mixed types. I instead opted to remove one value from each top-level key.

[SergioBenitez]

This should be removed to remove all of the special-casing.

[thorio]

@SergioBenitez I fixed all the issues with obvious solutions, I think the rest warrant further discussion.

The big benefit with the zip- strategies is the handling of "there is no value here" values, without it the Env provider would not work correctly for MYARRAY.0=10, MYARRAY.1=20. I picked None for this because it was the simplest option, as well as being fairly pointless in arrays (you'd just remove the entry and shorten the array instead of putting None there).

This also touches on #112, where the user wanted a way to specify "there is no value here", such that None would not replace the previous Some value.

So we need to differentiate between these three cases when merge-ing:

• "I have an incoming value and I want to replace the existing value" => Some(value)
• "I do not have an incoming value and want to remove the existing value" => None
• "I do not have an incoming value and want to leave existing value untouched" => ???

join-ing works the same way, with "incoming value" and "existing value" swapped.

Thus I think we do need something like Value::Void that will always be replaced, regardless of strategy, such that

            [1, 2, _, 4] 
merged with [_, 8, 3, _]
becomes     [1, 8, 3, 4]        where _ is this "void" value.