Add option to generate code with `IndexMap` instead of `HashMap`

[jon-zu]

Sometimes It's required to preserve the order, If we could add a flag to generate code with IndexMap instead of HashMap .
We could also just utilize serde_json::Map so It'd respect the serde_json feature flag.

[ahl]

Perhaps a generic "specify Map type" kind of setting? Some folks would prefer BTreeMap to HashMap so it might be nice to just allow this to be specified generically. I suppose we could do this for arrays and sets as well.

[jon-zu]

A special map type via settings is also a good choice, however It's somewhat convenient (can be also confusing ofc) that serde_json::Map is controlled over the feature flag in the Cargo.toml. So maybe allowing 3 options(Default, serde_json or custom) would be a decent setting. I can try to get a cli option working for this next week and make a pull request.

[ahl]

I'd welcome a pull request here. My suggestion is to provide an option for all modes (builder, macro, CLI) that lets you specify the fully qualified path of the map type you'd like. The assumption would be that it would be a type of the form T<K,V> that supports typical map-like operations (it would be nice in the docs if we specify what those map-like operations are specifically).

[JosiahBull]

@ahl Is there preference on the Syntax you'd like this to have?

Initially I think this should be implemented as a global option to change all maps, then extended later to be configurable per-type using the x-rust-type sytnax.

Are you happy with that solution?

[ahl]

My suggestion is that we introduce TypeSpaceSettings::with_map_type that takes a string that specifies the fully qualified path for a map-like type. Let's be specific in the docs about the operations we expect of a "map-like type".

Regarding the current proposal in #708, I don't think I love the use of an enum here--I'd rather be more flexible. Interacting with x-rust-type doesn't particularly seem right to me here. Is there a use case for having multiple map types appear in the generated types? I also don't think there should be a feature flag here (indeed, I don't think a dependency on the crate containing potential maps is required, except by associated with the actual, generated code).