[Epic]: Support returning values from client invocations

Support server to clients acks so that reliable messaging can be implemented more easily. This would only be when using `Clients.Client()`. I think we should go back to the SendAsync (fire and forget) InvokeAsync (wait for ack) naming pattern. That's the one sticking point.

EDIT by @anurse: For clarity, this issue is tracking all work related to allowing values to be returned from client invocations. It **also** covers allowing the server to wait for a `void`-returning (or `Task`-returning) client side method to complete.

### Work left for .NET 7

- [ ] his was already an issue with Task returning `.On` methods, but client results likely makes it more likely to block on the client side
- [ ] #41997
- Today we detect if you allow parallel hub invocations and throw if you don't when trying to use the feature. This doesn't work if you use `IHubContext` in the Hub, or if you have multiple waiting results for the same connections Hubs.
- This is also especially bad in `OnConnectedAsync` because that's a special method that runs before the receive loop starts, we need to throw/unblock/warn etc. for this
- [ ] Analyzer to warn about strongly-typed hubs and using `InvokeAsync` with `.All`, `.Group`, etc.
- [ ] `InvokeAsync` void result? Scenario, acks without needing a value
- [ ] [Scaleout] ServerA requests client result from connection on ServerB, ServerB goes down after receiving request, ServerA needs to know somehow so it can error the client result
- [ ] Look at performance
- The biggest performance issue I can think of right now is that `RawResult` allocates and copy the bytes which can be expensive
- [ ] Flow cancellation from server to client
- Inject `CancellationToken` into `.On` methods and send `CancelInvocation` hub messages to clients