Handle keys that look like integers

[yzadik]

I had to flatten and then unflatten json which had arrays and also some keys of the form "0", "1" (strings with numbers). I hacked on the code a bit disambiguate arrays from these keys by adding a "@", but the way I did it breaks backward compatibility. Here it is for reference:

yzadik@3302f14

[rorosentrater]

idk if this issue is related to the #48 issue referenced but, I am also observing this issue. I think the root of the problem is because of the way list indexes are flat packed.

# Original dict A
{'foo': ['a', 'b', 'c']}

is flat packed as:

# Flat dict A
'foo_0': 'a',
'foo_1': 'b',
'foo_2': 'c',

Which is identical to the way the following dict would also be packed:

# Original dict B
{
    'foo': {
        '0': 'a',
        '1': 'b',
        '2': 'c',
    }
}

Which again is flat packed as:

# Flat dict A
'foo_0': 'a',
'foo_1': 'b',
'foo_2': 'c',

and so both of these flat packed formats are unpacked into the same structure (NOT desired, as you can see we started with 2 very different JSONs/dicts)

Maybe this could be solved by changing how list item indexes are flat packed? I have seen other libraries use this format foo[0]: 'a' for list indexes, leaving the foo_0': 'a' format unambiguously a dict only format representing the key 'foo' which itself has a nested dict with the key '0'.

Though the above approach creates another bug if implemented because then what do you do if the original dict looks like this?

{
    'IAmJustAKeyName[0]': 'Not a list item'
}

^ This may be an acceptable bug until someone figures out how to fix that edge case though as I think mixing up list indexes and keys named just '0' is a much more common problem than unintentionally casting a key named 'foo[0]' to a list item.