Feedback on Swift API client generator

Description

After chatting with @banjun (the creator of https://github.com/banjun/SwiftBeaker), here are some feedbacks from him for the Swift API client generator:

# strongly typed either (multiple) response cases

not good: `(_ data: [Pet]?,_ error: Error?)`
…reads as `(nil, nil)` and `(non-nil, non-nil)` are possible.
good: `Result<[Pet], Error>` or `throws`

moreover, SwiftBeaker generates response enum with exact cases for multi-response endpoints.
https://github.com/banjun/SwiftBeaker/blob/482c5bdb9b4a5d82017ce37c32f6eb3a3383e216/Examples/05.%20Responses.swift#L105


# type-checked nullabilities

https://github.com/swagger-api/swagger-codegen/blob/master/samples/client/petstore/swift3/default/PetstoreClient/Classes/Swaggers/Models/Animal.swift

Generated models seem to have its default empty initializers `public init() {}`.
Default initializers can be used to bypass compiler checks.
When `className` is required, it should be non-optional `String` and be initialized with init params, in Swifty code.

Just using struct generates more simple models (if we can ignore the inheritance of api data structure definition. inheritance is too OOP…)

Swagger-codegen version

Latest master

Start by comparing the generated Swift models, including the referenced Animal.swift, with the linked SwiftBeaker response example. Clarify how multi-response endpoints should use typed Result or throws, how required nullability should be initialized, and whether struct models are in scope; done means generated Swift output enforces those constraints.