Generate convenience initializers that flatten some nested scopes

[czechboy0]

Creating input types is quite verbose because they contain multiple nested enums. (e.g. .ok(.init(headers: .init(), body: .json(...)))).

It may be useful to generate static helper functions on the output type so it's possible to write .ok(body: .json(...)) instead, or even .ok(...) directly.

We have to be careful here, though, as it's possible to go very far and generate a ton of conveniences, that end up making the API more difficult to understand. So will require a well thought-out proposal first, describing which high-value conveniences we should generate, and how we evaluate further requests.

We also need to keep in mind that the generator complexity shouldn't be significantly increased with this work, as per https://github.com/apple/swift-openapi-generator/blob/main/Sources/swift-openapi-generator/Documentation.docc/Articles/Project-scope-and-goals.md#principle-reduce-complexity-of-the-generator-implementation

[czechboy0]

For unwrapping, let's see if this could work: case let .ok(.json(response)):.

[simonjbeaumont]

@czechboy0 this would work in a guard/else. Is that what you hand in mind?

I think we still need some heuristics for what to name these and when to generate them.

I'm still not sure how much value that work will add when adopters can write the same in their code.

I think conveniences on for creating inputs and outputs will probably add more value. WDYT?

[czechboy0]

@czechboy0 this would work in a guard/else. Is that what you hand in mind?

Yeah, in a guard, if, or a switch. Just wanted to note here that once can unwrap more than one level in one go.

I think we still need some heuristics for what to name these and when to generate them.

Agreed. Right now I'm just dumping thoughts in this issue, I don't yet have a good idea of how we approach improving these.

[czechboy0]

Ah nevermind, that won't work as the response associate value us a struct, not the body enum itself.