b/357892637
following up on: #11477
This uses inprocess transport. Next we will add interop test using netty transport to test real across thread span propagation.

Context

io.opentelemetry.context forks io.grpc.context, so propagating span context becomes an issue.
In grpc, the server context is propagated from transport thread to the application thread at the JumpToApplicationThreadServerListener, using ContextRunnable. However, due to opentelemetry has its own context object/storage, the span propagation does not happen automatically with the existing grpc support. There are two ways of doing this:

1. (this PR) use the interceptor to explicitly propagate span to the application thread. (interceptor runs in application thread, serverStreamTracer.filterContext runs in transport thread).
   Pros: simplicity, UX, API support
   Cons:context does not propagate between opentelemetry and grpc, only span context is manually propagated.
2. Implement io.grpc.override.ContextStorageOverride, e.g. https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/grpc-1.6/library/src/main/java/io/grpc/override/ContextStorageOverride.java,
   which delegates the grpc context storage to opentelemetry context.
   Pros: propagate all
   Cons: UX is complicated. users can not it use with other custom ContextStorageOverride if we add it to grpc-opentelemetry package. Or if we release it as a separate artifact, users need to add dependency, no API support.

Client side is easier, the current span context in opentelemetry from the application will be propagated as parent span towards grpc client/attempt spans, automatically support by SpanBuilderImpl.