Allow negotiation of extensions

This discussion originally spawned from https://github.com/bazelbuild/bazel/issues/29267. As it stands today, the `GetCapabilities()` RPC doesn’t afford any mechanism for negotiation of non-standard extensions.

## Background

At the time of writing, Bazel has one well-known nonstandard extension: remote persistent workers. This is managed through the `persistentWorkerKey` platform property, which is sent to the remote executor when `--experimental_remote_mark_tool_inputs` is enabled. This feature is intended to be transparent: if a server doesn’t support persistent workers, it can effectively ignore the `persistentWorkerKey` platform property.

However, as written the REAPI spec explicitly states the following:
[https://github.com/bazelbuild/remote-apis/blob/becdd8f9ff811df88a22d3eadd6341753d51d167/build/bazel/remote/execution/v2/remote\_execution.proto\#L870-L873](https://github.com/bazelbuild/remote-apis/blob/becdd8f9ff811df88a22d3eadd6341753d51d167/build/bazel/remote/execution/v2/remote_execution.proto#L870-L873)

This means that compliant RE services are expected to reject *any* platform properties Bazel may send that the remote execution service is not explicitly aware of–whether or not doing so results in a well-defined fallback behavior.

This came to light when a new `persistentWorkerProtocol` platform property was introduced alongside `persistentWorkerKey` to enable proper handling of JSON-protocol remote persistent worker actions (in https://github.com/bazelbuild/bazel/pull/28489).

There are a number of other nonstandard platform properties that communicate various features, but the interactions of these are between end users and RE service providers. This is how platform properties are largely expected to be used. Some common examples are:

* `cache-silo-key` – Effectively a “salt” for action cache results.
* `container-image` – A docker container image to use in remote actions.

## Feature request

Introduce a mechanism to negotiate nonstandard capabilities between servers and clients. This allows REAPI clients to respond to server hints, and remain compliant with the REAPI protocol in a way that allows seamless interoperability when unsupported extensions are available.

While platform property negotiations are one way to implement this (since it's an easy way to place arbitrary metadata in `Action` messages), this feature request isn’t strictly tied to that approach.