Provide a general mechanism for server handler configuration/behaviour extension

[#6477f53](https://github.com/apache/pekko-grpc/commit/6477f539792c1a96fe799fc9b3e7abd9990) introduced an implicit `GrpcServerSettings` for server handlers, and introduced a [specific `GrpcMarshalling.negotiate`) variant](https://github.com/apache/pekko-grpc/commit/6477f539792c1a96fe799fc9b3e7abd9990d3a55#diff-89817a0a1f4a6377f320c5d7247026a84eeb520f85d772482e76520c1eb98a88R120-L126) that accepts a maximum message size.

#747 also proposes [another `GrpcMarshalling.negotiate`) variant](https://github.com/apache/pekko-grpc/pull/747/changes#diff-5f9fe333ca414b8e658edbed6ca2d112e3e6c82691088a385cab20fd4b9f708bR69) for negotiating behaviour with compression enabled.

It would be good to avoid this proliferation and consolidate on a single `GrpcMarshalling.negotiate` that takes a more general "server handler context" that allows for:
- customisation of the handler in various ways via configuration
- extension of the handler behaviour (e.g. adapters, interceptors)

The interceptors feature is a long-standing missing feature of `pekko-grpc` (inherited from `akka-grpc`). There are workarounds using `pekko-http` for some use cases, but for others it gets a bit awkward - the primary example from my experience is establishing thread local contexts (e.g. Spring security, or OTEL/Micrometer tracing/observation context, application auditing etc.) for gRPC implementations.
These currently require some version of AOP (i.e. I use Spring advisors), but are rather fragile/delicate - i.e. in my case utilising AOP pointcuts matching on the Power API signatures and reflective extraction of the `Metadata` parameter.
A full implementation of behaviour extension would ideally include `Metadata` attributes as well, so there's broader work there, but providing the basic hook in 2.0 would allow these behaviours to be added later without breaking API/ABI.

I'm imagining something like a `ServerHandlerContext` that initially only contains a `GrpcServerSettings` instance, which is passed to the applicable `negotiate` and marshalling methods.

CC: @pjfanning , @He-Pin

Start by reading GrpcMarshalling.negotiate, the existing GrpcServerSettings handling, and the applicable marshalling methods. Trace how server handlers receive settings and compare the existing maximum-message-size and compression variants. Done means a documented general context mechanism supports configuration and leaves room for handler behaviour extensions without breaking API or ABI.

Written by the indexing model from the issue text.