Add "primary output" to RequestMetadata

[sluongng]

In Bazel, there are many cases where a combination of <target label> + <action mnemonic> - <configuration> is not sufficient to identify an action.

For example, given a cc_library target with a lot of source files

cc_library(
    name = "foo",
    srcs = [
        "foo1.cc",
        "foo2.cc",
        "foo3.cc",
    ],
    hdrs = ["foo.h"],
)

Then there will be 3 separate CcCompile actions with the identical combination above.
This is unfortunate because our RequestMetadata message is mapping to that exact combination and therefore, makes it challenging for servers to differentiate ByteStream.Write requests that were made for CcCompile(foo1.cc) and CcCompile(foo2.cc).

The solution for this, unfortunately, is to add another field to RequestMetadata:

--- a/proto/remote_execution.proto
+++ b/proto/remote_execution.proto
@@ -2486,6 +2486,10 @@ message RequestMetadata {
   // or equality across invocations, though some client tools may offer these guarantees.
   string configuration_id = 7;

+  // An identifier for the expected set of outputs which are produced by this action.
+  // e.g. the first entry among the [Command][build.bazel.remote.execution.v2.Command]'s output_paths.
+  string primary_output = 8;
+

This way, we can avoid breaking server/client relying on existing fields.

[sluongng]

This was originally discussed in Slack via https://bazelbuild.slack.com/archives/CA31HN1T3/p1752841521236659

with @mattem and @illicitonion involved

[sluongng]

Just a basic example. Here is a mock UI of how BuildBuddy Remote Cache requests would look like today for a big cc_library target in Bazel

There are multiple Action Cache hits for the same //foo/bar:bar target label with CppCompile mnemonic, all with the same configuration (aka target platform).

We want to have the ability to disabiguate these requests using the RequestMetadata: which one was the one used to compile cat.cc and which one was used to compile dog.cc.

[sluongng]

This may partially address #341 as well. But folks there seem to prefer a different solution