Add support for other Object types

[ecton]

The base Object type is good insofar that it works with no_std with no dependencies. However, we should have support for HashMaps and ideally IndexMap as well. This will give faster random access to the parsed data structure.

My thought is to add a new generic parameter to Value which controls the object backing. Default parameters aren't great in some situations (like From), so we might want to consider making Value an alias for JsonValue<'a, Object<'a>> to minimize code breakages.

[ecton]

I have, but I don't like the implementations that force the users into a specific implementation based on feature flags. That causes potential compatibility issues between multiple crates that maybe request different features to be enabled.

I also can't use HashMap directly because it requires std, which is why the current implementation uses Vec. This is why I'm leaning towards an approach I haven't seen other crates do: a generic parameter to customize what the contained object type is.

The other edge case that BTreeMap/IndexMap/HashMap doesn't support is when a JSON object has duplicate keys. Technically, nothing in the specification prevents this, but using one of those map types may cause issues.

[ecton]

Believe it or not, there are people who do want this in no_std environments (#1). It was literally the first requested feature.

Regardless, I think the approach I outlined in the initial comment is a good approach that will allow supporting any map type, giving users ultimate flexibility in how they want to consume their JSON.