Implement web sockets in Hyperspace

[GrandLarseny]

This is more of a proposal to track adding support for web sockets to Hyperspace. I believe it would be an interesting use case that could be helpful.

Implementation

I propose adding a new class named WebSocketBackendService that conforms to BackendServiceProtocol. It will behave very similarly to BackendService, but will add two key functions.

func listen<T>(for type: T, perform: (T) -> Void) where T: Decodable
func send<T>(message: T) async throws

Alternatives Considered

I have considered registering decodable types in the service initializer, but I believe that losing the type information would be pretty rough in the implementation. I like how the above listen function would maintain type information which allows the implementers to treat listening to messages similarly to routing URLs.

Drawbacks

Bloat. Adding web sockets is a bit outside the initial scope of Hyperspace, but I believe it is appropriate for this framework since it's an Apple-supplied and supported API.

[GrandLarseny]

After digging in for a little while it's clear that I'll need to add a few more layers, including WebSocketTransportService, TransportWebSocketTask, and add a function to TransportSession to vend web socket tasks.

[wmcginty]

To combat the bloat drawback - would this be something that could be implemented as a separate Swift Package / Cocoapod that has a dependency on Hyperspace? I guess a lot would depend on how integrated the interfaces need to be, but we could also tailor the core Hyperspace interface to be a bit more extendable as needed.

Also, knowing that in a future release we'll likely be losing the concept of the core TransportDataTask as it gets replaced by async equivalents (see #160), I think it strengthens that argument to make this task-based functionality a separate package.

[GrandLarseny]

Ah, good point about removing TransportDataTask. Speaking of which I owe you a review of your PR.

First off, I am definitely not opposed to this being a separate package dependent upon Hyperspace. To me it's a matter philosophy about what we're trying to do with Hyperspace, and our frameworks in general. I agree with the position that we want to be focused, avoiding the pitfalls of frameworks that try to be all things to everyone (to be honest there are features like the activity indicator that I think we might want to move out to focus the framework more).

I guess my thought about including web sockets in Hyperspace is that they're included as part of the URLSession, same as a streaming task or upload task. Do we want to have Hyperspace cover only download tasks? Data tasks? And everything else is a separate framework?

Or is Hyperspace intended to help with all things URLSession?

After all this I think I'm talking myself into a separate package. Web sockets, uploads, and streaming tasks would want to have pretty different strategies in general. No reason to bog down Hyperspace with that.