Add ability to update GrpcCapabilities during specialization

[brettsam]

For dotnet-isolated, we'll eventually need the ability for a worker, during specialization, to report different capabilities than the placeholder worker ran with.

We need to add the ability for a worker to return back new capabilities during an EnvironmenReloadResponse, which will then be applied to the GrpcWorkerChannel's capabilities.

We should take this opportunity to refactor the GrpcCapabilities, as well. We should not be checking and parsing capabilities on every invocation like this:

azure-functions-host/src/WebJobs.Script.Grpc/Extensions/ScriptInvocationContextExtensions.cs

Lines 26 to 27 in fe291a2

	bool excludeHttpTriggerMetadata = !string.IsNullOrEmpty(capabilities.GetCapabilityState(RpcWorkerConstants.RpcHttpTriggerMetadataRemoved));

. Instead, we should parse this upfront and just pass bools around. I benchmarked this -- it adds ~15 nanoseconds. Not crazy, but still not needed on every invocation.

[kshyju]

We also need to include worker metadata, which includes information such as worker runtime and worker package version info etc.

https://github.com/Azure/azure-functions-dotnet-worker/blob/7d659ced053af41d58274ea4a36d2b5db2138750/src/DotNetWorker.Grpc/GrpcWorker.cs#L197-L203

[fabiocav]

Closing this as completed. @kshyju will be creating a new issue to track the lookup improvement mentioned above.