Add support for Windows (#71)
Implement the lock primitive.

Change 'unsafeDowncast' to 'as!' (#52)
Motivation:
The 'unsafeDowncast' can cause a miscompile leading to unexpected
runtime behaviour.
Modifications:
- Use 'as!' instead
Result:
No miscompiles on 5.10

Set OutputStream.delegate to nil in HTTPBodyOutputStreamBridge.deinit (…
…#46)
### Motivation
When running the cancellation tests in a loop, very occasionally there
would be a crash with the following backtrace:
```
#0	0x000000018aa008d4 in objc_opt_respondsToSelector ()
#1	0x000000018aea3410 in _outputStreamCallbackFunc ()
#2	0x000000018aea3310 in _signalEventSync ()
#3	0x000000018aeecdb0 in ___signalEventQueue_block_invoke ()
#4	0x000000018abe6cb8 in _dispatch_call_block_and_release ()
#5	0x000000018abe8910 in _dispatch_client_callout ()
#6	0x000000018abefea4 in _dispatch_lane_serial_drain ()
#7	0x000000018abf0a08 in _dispatch_lane_invoke ()
#8	0x000000018abfb61c in _dispatch_root_queue_drain_deferred_wlh ()
#9	0x000000018abfae90 in _dispatch_workloop_worker_thread ()
#10	0x000000018ad96114 in _pthread_wqthread ()
```
This seems to indicate that the output stream is trying to access its
delegate. However, when running with debug logging enabled I can see
that the delegate has already been deinitialized.
This is likely a result of the delegate itself owning the stream and
setting the stream delegate to `self`, which IIUC is an established
pattern. This presents a race in teardown.
### Modifications
This patch sets the output stream delegate to `nil` in the delegate
`deinit`.
### Result
No attempts to call the delegate will happen after it is has been
deinitailzed.
### Test Plan
With this patch, the failing test passes when run an order of magnitude
more times than were required to reliably reproduce the crash without
the patch.

More checks for task cancellation and tests (#44)
### Motivation
In our fallback, buffered implementation, we did not use a task
cancellation handler so were not proactively cancelling the URLSession
task when the Swift concurrency task was cancelled. Additionally, while
we _did_ have a task cancellation handler in the streaming
implementation, so the URLSession task would be cancelled, we were not
actively checking for task cancellation as often as we could.
### Modifications
- Added more cooperative task cancellation.
- Added tests for both implementations that when the parent task for the
client request is cancelled that we get something sensible. Note that in
some cases, the request will succeed. In the cases where the request
fails, it will surface as a `ClientError` to the user where the
`underlyingError` is either `Swift.CancellationError` or `URLError` with
`code == .cancelled`.
### Result
More cooperative task and URLSession task cancellation and more thorough
tests.
### Test Plan
Added unit tests.

Bump to 1.0.0-alpha.1 (#36)
Bump to 1.0.0-alpha.1
### Motivation
Prepare for 1.0.0-alpha.1.
### Modifications
- Updated runtime dependency.
- Updated docs.
### Result
Ready to tag 1.0.0-alpha.1.
### Test Plan
All tests pass.
Reviewed by: simonjbeaumont
Builds:
     ✔︎ pull request validation (5.10) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 
#36

Replace AsyncBackpressuredStream with updated implementation (#29)
### Motivation
As a follow up to #27, we noted it would be good to align on the latest
draft implementation of SE-0406 (AsyncStream with backpressure) to both
pickup the latest improvements in performance and correctness, and to
minimise the churn if/when this lands in the standard library or
standalone package.
### Modifications
In order to simplify reviewing the following modifications have been
made in independent commits:
* `Add updated SE-0406 implementation as BufferedStream, incl. tests`:
Skim over this—it's vendored in wholesale.
* `Port the custom watermark support to BufferedStream`: Skim over
this—it's a 1:1 port of the logic that was added to
`AsyncBackpressuredStream`.
* `Switch from AsyncBackpressuredStream to BufferedStream in delegate`:
Review this—it's a minimal change.
* `Remove AsyncBackpressuredStream and its vendored locks`: Skim over
this—it's removing the old implementation.
### Result
No functional change, but the internal async sequence we're using should
be more robust, performant, and more likely to match a future standard
library type.
### Test Plan
- The new vendored `BufferedStream` actually comes with a much greater
number of vendored tests than the previous revision.
- Also ported the tests from this repo for the custom watermark logic.
- All our URLSessionTransport-specific tests continue to pass.
---------
Signed-off-by: Si Beaumont <beaumont@apple.com>

[URLSession Transport] Async bodies + swift-http-types adoption (#15)
[URLSession Transport] Async bodies + swift-http-types adoption
### Motivation
URLSession transport changes of the approved proposals apple/swift-openapi-generator#255 and apple/swift-openapi-generator#254.
### Modifications
- Adapts to the runtime changes, depends on HTTPTypes now.
- Doesn't do streaming yet, we'll addressed that separately, continues to buffer for now (apple/swift-openapi-generator#301)
### Result
Transport works with the 0.3.0 runtime API of.
### Test Plan
Adapted tests.
Reviewed by: simonjbeaumont
Builds:
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 
#15

Fix double encoding of path parameters (#14)
Fix double encoding of path parameters
### Motivation
Fixes apple/swift-openapi-generator#251.
### Modifications
Use the already escaped path setter on `URLComponents` to avoid the second encoding pass.
### Result
Path parameters that needed escaping are only escaped once, not twice.
### Test Plan
Adapted the existing unit test to cover a path item that needs escaping.
Reviewed by: simonjbeaumont
Builds:
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 
#14

Docs fixes (#13)
Docs fixes
### Motivation
Docs should be correct.
### Modifications
Update docs with the latest versions.
### Result
N/A
### Test Plan
N/A
Reviewed by: dnadoba
Builds:
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 
#13

Prepare being compatible with runtime 0.2.0 release (#12)
Prepare being compatible with runtime 0.2.0 release
### Motivation
Runtime 0.2.0 is compatible with 0.1.3+ in the APIs adopted in the transport, so just reflect that in the manifest.
### Modifications
Increased the supported runtime range to include 0.2.x.
### Result
Once released, folks will be able to use 0.1.x of this transport with both 0.1.x and 0.2.x of runtime.
### Test Plan
Will be manually tested once runtime 0.2.0 is released.
Reviewed by: gjcairo
Builds:
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 
#12