Add OpenTelemetry middleware

[anuraaga]

Initial implement with basic tracing / propagation. Follow-ups will add opt-in metadata attributes and metrics.

Some questions

• Whether to use a separate package at all. As an "OTel guy" I'm happy to go with native instrumentation built into the library as I did with pyqwest (single dep on opentelemetry-api) but started with middleware since it's more common.
• PyPi package name - I went with connectrpc-otel hoping we will publish to connectrpc eventually (not sure the latest on that)
• Whether to use a workspace package vs separate repo. It probably won't really depend on much of conenctrpc and could be better to version separately, but it becomes easier to lose track of the repo

Happy with any direction for these.

https://opentelemetry.io/docs/specs/semconv/rpc/connect-rpc/

[anuraaga]

I only added unit tests for unary for now since I'll probably avoid the stream-type specific interceptors after #149

[stefanvanburen]

• Whether to use a workspace package vs separate repo. It probably won't really depend on much of conenctrpc and could be better to version separately, but it becomes easier to lose track of the repo

Are we able to keep the upstreamed PyPI version completely separated? I think as long as we can do that, it's probably ok to keep in this repo — I think we avoided it with Go because it's annoying to do multi-module versioning in a single repo, and probably borrowed that approach for the -es repos (like @connectrpc/validate).

If we can do e.g. tag connectrpc-otel/0.1.0 and have that release just that package, probably fine? I don't know exactly how all the recent python tooling works with this sort of set up. Just wanted to get your thoughts before taking a closer look.