Apply the same .swift-format as the generator repo

### Motivation

Bring the runtime library formatting in line with the generator repo.

Also fixes apple/swift-openapi-generator#250.

### Modifications

Copied the `.swift-format` file, reran swift-format.

Only formatting changes.

### Result

Consistent style.

### Test Plan

CI.


Reviewed by: gjcairo

Builds:
     ✔︎ pull request validation (5.10) - Build finished. 
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (api breakage) - Build finished. 
     ✔︎ pull request validation (docc test) - Build finished. 
     ✔︎ pull request validation (integration test) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 

#68

…label (#71)

### Motivation

- Fixes
[#369](apple/swift-openapi-generator#368)

### Modifications

- Remove init label argument from Base64EncodedData

### Result

- The Base64EncodedData init will be called without the label.

### Test Plan

- Adjust some tests from Test_OpenAPIValue

[Multipart] Introduce a bytes -> frames parser

### Motivation

Start landing the parts of the multipart machinery that is unlikely to change as part of the multipart proposal that's finishing review tomorrow.

### Modifications

Introduce a bytes -> frames parser and an async sequence that wraps it.

A "frame" is either the full header fields section or a single chunk of a part body.

### Result

We can now frame bytes of a multipart body.

### Test Plan

Added unit tests for the state machine, the parser, and the async sequence.


Reviewed by: simonjbeaumont

Builds:
     ✔︎ pull request validation (5.10) - Build finished. 
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (api breakage) - Build finished. 
     ✔︎ pull request validation (docc test) - Build finished. 
     ✔︎ pull request validation (integration test) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 

#72

### Motivation

Surface the Swift version and platform support status from Swift Package
Index.

### Modifications

Added badges, plus a quick link to the docc docs, to the top of the
README.

### Result

Easier to quickly see our support matrix, plus the quick link to docs.

### Test Plan

Previewed locally.

### Motivation

Second state machine, doing the inverse of #72, serializes frames into
bytes.

### Modifications

- A new state machine.
- A new serializer wrapping the state machine.
- An async sequence wrapping the serializer.

### Result

We can now serialize multipart frames into bytes.

### Test Plan

Unit tests for all 3 layers.

[Multipart] Validation sequence

### Motivation

The OpenAPI document provides information about which parts are required, optional, arrays, and single values, so we need to enforce those semantics for the adopter, just like we enforce (using JSONDecoder) that a received JSON payload follows the documented structure.

### Modifications

Since the mutlipart body is not a struct, but an async sequence of parts, it's a little more complicated.

We introduce a `MultipartValidationSequence` with a state machine that keeps track of the requirements and which of them have already been fulfilled over time. And it throws an error if any of the requirements are violated.

For missing required parts, the error is thrown when `nil` is received from the upstream sequence, indicating that there will be no more parts coming.

To implement this, an internal type `ContentDisposition` was also introduced for working with that header's values, and helper accessors on `MultipartRawPart` as well.

### Result

Adopters don't have to validate these semantics manually, if they successfully iterate over the parts without an error being thrown, they can be confident that the received (or sent) parts match the requirements from the OpenAPI document.

### Test Plan

Unit tests for the sequence, the validator, and the state machine were added. Also added unit tests for the `ContentDisposition` type.


Reviewed by: simonjbeaumont

Builds:
     ✔︎ pull request validation (5.10) - Build finished. 
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (api breakage) - Build finished. 
     ✔︎ pull request validation (docc test) - Build finished. 
     ✔︎ pull request validation (integration test) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 

#76

[Multipart] Add public types

### Motivation

Add the public types approved in SOAR-0009.

### Modifications

Added the public types and make other changes outlined in SOAR-0009.

### Result

Most of the required runtime types are now in place.

### Test Plan

Added unit tests for the new code, where it made sense.

⚠️ The pipeline `pull request validation (api breakage)` is failing with:

```
1 breaking change detected in OpenAPIRuntime:
  💔 API breakage: constructor Configuration.init(dateTranscoder:) has removed default argument from parameter 0
** ERROR: ❌ Breaking API changes detected.
```

but that seems to be a false positive in the tool, as there is now a newer initializer that you can use as `.init()`, `.init(dateTranscoder:)`, `.init(multipartBoundaryGenerator:)`, or `init(dateTranscoder:multipartBoundaryGenerator:)`, so no existing code could be broken by this change.


Reviewed by: simonjbeaumont

Builds:
     ✔︎ pull request validation (5.10) - Build finished. 
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (docc test) - Build finished. 
     ✔︎ pull request validation (integration test) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 
     ✖︎ pull request validation (api breakage) - Build finished. 

#77

[Multipart] Add converter SPI methods

### Motivation

Last planned runtime PR for multipart, this adds the remaining SPI methods that allow the generated code to serialize/deserialize multipart bodies, both for client and server.

### Modifications

Added SPI methods on `Converter` for multipart.

### Result

Client and server generated code can now serialize/deserialize multipart bodies.

### Test Plan

Added unit tests for the SPI methods.


Reviewed by: simonjbeaumont

Builds:
     ✔︎ pull request validation (5.10) - Build finished. 
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (api breakage) - Build finished. 
     ✔︎ pull request validation (docc test) - Build finished. 
     ✔︎ pull request validation (integration test) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 

#78

### Motivation

The associated value of enum case `HTTPBody.Length.known` was `Int`,
and, on watchOS, `Int = Int32`, which is not ideal for a content length.

### Modifications

- (API breaking) Change type of HTTPBody.Length.known from Int to Int64.

### Result

Can now express larger values for content type on 32-bit platforms.

### Test Plan

Unit tests pass.

### Related Issues

- Fixes apple/swift-openapi-generator#354.

### Note

I have marked this PR as `semver/major` as it constitutes the first of
the PRs we make in the run up to 1.0.0-alpha.1 and the release notes
generator should therefore catch us from inadvertently cutting another
pre-1.0 patch release.

### Motivation

Part of addressing
apple/swift-openapi-generator#75 and
apple/swift-openapi-generator#119.

### Modifications

Bumped Swift tools version to 5.9 and made the `ExistentialAny` build
setting unconditional.

### Result

Building the package requires 5.9 now.

### Test Plan

Ran tests, all passed when using a Swift 5.9 toolchain.

### Motivation

Preparing for 1.0.0-alpha.1, remove deprecated code.

### Modifications

Removed deprecated code.

### Result

No more deprecated code.

### Test Plan

All tests pass, no warnings.

Bump version docs to 1.0.0-alpha.1

### Motivation

_[Explain here the context, and why you're making that change. What is the problem you're trying to solve.]_

### Modifications

_[Describe the modifications you've made.]_

### Result

_[After your change, what will change.]_

### Test Plan

_[Describe the steps you took, or will take, to qualify the change - such as adjusting tests and manual testing.]_



Reviewed by: simonjbeaumont

Builds:
     ✔︎ pull request validation (5.10) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (api breakage) - Build finished. 
     ✔︎ pull request validation (docc test) - Build finished. 
     ✔︎ pull request validation (integration test) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 

#82

### Motivation

While this isn't technically necessary, as all versions of a platform
not explicitly mentioned are assumed to be supported, it's better to be
explicit here.

### Modifications

Add `visionOS(.v1)` to the list of supported platforms.

### Result

Clearer support matrix.

### Test Plan

N/A, this is basically just a documentation change.

See apple/swift-openapi-generator#396.

---------

Co-authored-by: Honza Dvorsky <[email protected]>

### Motivation

Ensure all symbols are curated.

### Modifications

Added symbols that were showing up in automatic sections to existing
curated sections.

### Result

All symbols are curated.

### Test Plan

Built docs locally.

### Motivation

Prep docs for 1.0.

### Modifications

See above.

### Result

Ready to tag 1.0.

### Test Plan

Manual inspection.