bad results when using multiple Rust types with the same name

In https://github.com/oxidecomputer/omicron/pull/1210 I saw a case where we had multiple Rust types with the same name (well, in different modules) -- one was used as an input type and one as an output type. Only one of these made it into the OpenAPI spec. It seems like this could result in all kinds of bad behavior. For example, suppose type A is used in the spec where type B was meant. At best, if B is an input type, and the types are totally different, then every request that used type B as input would probably fail validation and there'd be no way to call them (using a spec-generated client). At worst, if the types are similar but type B has an optional field that's not in type A, dropshot would be silently corrupting data on input (silently deleting a field from the struct). I think you could have the same thing on output.

Start by examining the multiple same-named Rust types described in PR 1210 and trace how they are represented in the OpenAPI spec. Determine how input and output types can be distinguished without silently selecting the wrong type; done means both types are represented correctly and generated-client validation and data handling no longer use the wrong schema.