Cardinality violations should use error code “unimplemented”

The gRPC docs for error codes state that both client and server should use the `unimplemented` code for cardinality violations. See table at the bottom of this doc (you can search for “cardinality violation” in the doc): https://grpc.github.io/grpc/core/md_doc_statuscodes.html.

A cardinality violation is when a stream contains an incorrect number of messages. Specifically, when a response stream for a unary or client-stream RPC contains zero messages with an OK status or more than one message; or when a request stream for a unary or server-stream RPC contains zero or more than one messages.

The server in this repo reports an exception with an `internal` error in this situation instead of `unimplemented`.

The client’s behavior is a little more… interesting:

1. For unary RPCs, if no response messages are present in the response, only an “OK” status, an exception with an `internal` error is thrown.
2. For client-stream RPCs, if no response messages are present in the response, only an “OK” status, there is no error at all. The `onNext` and `onError` methods of the application’s `StreamObserver` are never called, but the `onCompleted` method is.
3. For both unary and client-stream RPCs, if a second response message is erroneously sent by the server before the trailers/status, an error is reported that has a `cancelled` code and a message of “Failed to read message.” Presumably the code comes from the fact that the library is likely trying to cancel the operation to prevent receipt of any further unwanted messages in the response stream.