Stabilize Dispose patterns

[AArnott]

Customers have reported a few times that they want to Dispose of JsonRpc (or indirectly its MessageHandlerBase):

1. from their Disconnected event handler
2. while outbound messages are still in progress or perhaps even in transmission.

We know that disposing the MessageHandlerBase while messages are being transmitted is very problematic (e.g. dotnet/roslyn#18563).
And I suspect disposing from our event handler has undefined behavior.

1. I think we should add a test for the disposal from our event handler if we can make that work (for user convenience).
2. We should stop disposing our AsyncSemaphore in MessageHandlerBase.Dispose. There are no native resources to release, and this would avoid random exception types being thrown on our transmission thread, sometimes leading to crashes. Instead, we can set a boolean field so that any future transmission request is denied with an ObjectDisposedException.

Also: when is ObjectDisposedException thrown compared to ConnectionLostException? Even OperationCanceledException can be thrown back to pending requests due to a disconnection.

[AArnott]

I've re-opened microsoft/vs-threading#105 where we might place the fix for no. 2 above.

[AArnott]

No. 2 above is indeed resolved by microsoft/vs-threading#493

[tmat]

This would be very useful. We need to get to a state when remote calls can only throw 4 types of exceptions that correspond to

1. Connection issue (connection dropped for any reason)
2. Serialization issue - bug in serialization of arguments (types are not serializable, etc.)
3. Remote exception - an exception was thrown by the callee
4. Cancelation

Also, when a connection is dropped and CancelLocallyInvokedMethodsWhenConnectionIsClosed is set the connection dropped exception [1] should not be thrown. Instead a the cancellation token should be signaled and OperationCancelledException should be thrown ([4]).