some thoughts on the simplification of factory context

These thoughts stem from some completely unreleated work. I originally intended to simplify the interfaces of `ClusterInfo` and try to aggregate all HTTP reletated options to a single `HttpProtocolOptions`. Then, I found that the `TransportSocketFactoryContext` instance of cluster is prapagated in the multiple-levels call and I did a simplifiation (see #26438).

When I was doing #26438, I found that there are lots of types of factory context. All these factory contexts have some similar interfaces that used to access the server-wide resource. In almost all the cases, these interfaces' impl would be a simple wrapper to the interfaces of a server factory context reference.

I am thinking could we make things simpler, could we just add a `serverFactoryContext()` to these factory contexts to return a reference. **This reference will provides server-wide resource accessing.**
The type of reference could be `ServerFactoryContext` or `CommonFactoryContext` or `FactoryContextBase`, it depends on the set of interface that we want to expose.

Then we will have a clear delimitation between the server-wide resource and context-wide resource. And these factory contexts needn't inherit and implement the interfaces of `CommonFactoryContext` or `FactoryContextBase`.

And by this way, the code should be eaiser to maintian. Take #23903 as an example, in the #23903, we changed the return type of `admin()` interface. Although this interface is only accually implemented by the server, we still need to change almost every factory context because almost all factory contexts inherit the `FactoryContextBase`. (From this perspective, composition over inheritance).