Add a CallOption for modifying the :authority header

[110y]

This PR just adds a CallOption that makes us able to modify the :authority header per RPC.

Related: #5361

My use case for modifying :authority header per RPC

I'm using Google Cloud Run, a managed container platform, for running my applications.
Google Cloud Run creates a dedicated domain for each deployment like my-service-xxx.run.app.
In addition to this dedicated domain, Google Cloud Run also accepts a HTTP (gRPC) request on the single domain run.app and routes a request based on the :authority header like below:

This dynamic routing capability is very useful if grpc-go has a CallOption for modifying the :authority header per RPC instead of the per connection basis.
For example, let's assume we have two gRPC Servers, Server A and B, and develop two features for Server B simultaneously. When we deploy each feature as a dedicated server (B-1 and B-2) and if Server A can modify the :authority header for Server B based on its incoming header (metadata), developers can choose which Servers (B-1 or B-2) does Server A send the request dynamically like below:

To achieve this dynamic routing, we can use the Authority CallOption introduced by this PR like below:

conn, err := grpc.DialContext(ctx, "run.app:443", grpc.WithDefaultCallOptions(grpc.Authority(func(ctx context.Context, authority string) string {
	md, ok := metadata.FromIncomingContext(ctx)
	if !ok {
		return authority
	}

	headers := md.Get("test-service-b-target")
	if len(headers) == 0 {
		return authority
	}

	return fmt.Sprintf("service-b-%s-xxx.run.app", headers[0])
})))

---

I know there are concerns about modifying the :authority regarding TLS as described in this issue, but I think adding a CallOption for modifying authority might be able to be implemented independently.

P.S.
I know this PR does not include any test for the new CallOption. If this PR is acceptable I'd like to finalize this PR by writing tests, so I would appreciate it if anyone could let me know the right place to write the test for this type of change.

[110y]

I'm not fully confident about the signature of this modifier function (this is a user-facing API), but at least, I think it's worth making it have context.Context as its argument since we can use values inside the Context (e.g. metadata) for :authority modification as I described in the description of this PR.

[110y]

I think this PR needs to be tweaked after #5748 has been merged.

[easwars]

I know there are concerns about modifying the :authority regarding TLS as described in #5361, but I think adding a CallOption for modifying authority might be able to be implemented independently.

The concerns mentioned in that issue are valid and we would not want to introduce a call option to override the :authority header, without performing the checks mentioned in that issue. Unless the transport credentials agrees with the :authority override, it is not a wise thing to be doing.

Therefore, this PR as it stands currently, is not what we can move forward with. Please let us know if you are willing to update this PR with all the functionality described in #5361.

Thank you.