CLI generation fails for array-like and object-like query parameters

[ahl]

#1017 added support for query parameters that serialize into maps or arrays (in addition to ones that serialize into strings), but this didn't consider how this might be handled for CLI generation. In generated CLIs, query parameters become CLI flags and are handled with code like this:

            ::clap::Arg::new("id")
                .long("id")
                .value_parser(::clap::value_parser!(types::GetThingOrThingsId))
                .required(false),

...
        if let Some(value) = matches.get_one::<types::GetThingOrThingsId>("id") {
            request = request.id(value.clone());
        }

This is going to require some additional sophistication.

For a query parameter that's an array, we'll need something like this:

            ::clap::Arg::new("id")
                .long("id")
                .value_parser(::clap::value_parser!(String))
                .action(::clap::ArgAction::Append)
                .required(false),
...
        if let Some(value) = matches.get_many("id") {
            request = request.id(value.copied().collect());
        }

For map/object types we'll need to handle them a bit like we do body parameters.

This gets worse for untagged enums e.g. a type like this:

    #[serde(untagged)]
    pub enum GetThingOrThingsId {
        Variant0(::std::string::String),
        Variant1(::std::vec::Vec<::std::string::String>),
    }

... and still worse if we consider heterogeneous enums. For example, what parameter would we provide to clap::value_parser!?

Imagine a query parameter that's either a single number or an array of strings. That seems pretty hard to model with clap... and--fortunately--also an extremely contrived API!