Expose ServerCallStreamObserver to server-side stubs

### Is your feature request related to a problem?
At the moment, service methods of a base class for the server implementation (generated by `compiler/src/java_plugin/cpp/java_generator.cpp`'s `PrintAbstractClassStub`/`PrintStub`) have a `responseObserver` formal parameter of `io.grpc.stub.StreamObserver` type, despite that in runtime it is always an instance of `io.grpc.stub.ServerCallStreamObserver`, and using it requires a typecast, which is explicitly stated in its javadoc:

> An instance of this class is obtained by casting the {@code StreamObserver} passed as an argument to service implementations.

While this is not a disaster, and just takes some time to figure out the intended way of using server-side APIs (such as `setCompression(String)`) and can be improved even further by adding more details of this in the documentation, it still
1. Requires a boilerplate type casting inside of a service method (I currently see 30+ expressions similar to`final ServerCallStreamObserver responseObserver =(ServerCallStreamObserver) observer;` in grpc-java's own test code).
2. Does not give a clear understanding of an actual argument's type by simply looking at a generated code.
3. Potentially opens a way for an implementation issue where a non-`ServerCallStreamObserver` instance can be passed in runtime.

### Describe the solution you'd like
Since server call stream observer (along with a client one) [is already considered a stable and non-experimental feature](https://github.com/grpc/grpc-java/issues/1788), it may be practical to use a refined type explicitly in generated stubs (instead of a `io.grpc.stub.StreamObserver` interface) to give a developer a clear and robust way of calling relevant APIs and leave less room for an implementation error/deficiency.
On a side-note: one more potential improvement is to make it an interface instead of abstract class once `io.grpc.stub.CallStreamObserver` [becomes a non-experimental feature](https://github.com/grpc/grpc-java/issues/8499) to explicitly mark it as a part of gRPC API and allow for slightly easier mocking.

### Describe alternatives you've considered
Continue the current approach with a certain documentation improvement, e.g. adding a note on the usage of refined abstract classes to [Generated-code reference article](https://grpc.io/docs/languages/java/generated-code/).