Clean up --experimental_remote_mark_tool_inputs

[armandomontanez]

--experimental_remote_mark_tool_inputs is required for remote persistent workers to function correctly:

• https://www.buildbuddy.io/docs/rbe-platforms/#remote-persistent-worker-properties
• https://docs.engflow.com/re/client/remote-persistent-workers.html#client-side-requirements
• https://github.com/buildfarm/buildfarm/blob/127b6c6ad97cc2fc3933aa95646a219c5473598d/src/main/java/build/buildfarm/worker/Executor.java#L488

This flag was first introduced in Bazel 6.0.0, and doesn't describe any reason users should keep it disabled. As-is, this appears to be unnecessary boilerplate for remote persistent workers. One of the following should be done:

1. Enable the flag by default, and target a version for removal.
2. Document the tradeoff that justifies why this flag is off by default.

[fmeum]

I am also interested in flipping this. Before we stabilize the feature, we should probably:

1. Add better test coverage. The existing test didn't really cover lots of the edge cases before 97112f0, which added a runfiles tree to the inputs. Other types of artifacts (symlinks, directories, ...) should be added. There's also no full e2e test - we should add support to RemoteWorker and add one.
2. Document this feature (e.g. at https://bazel.build/remote/creating).
3. Rethink the way tools are labeled in Merkle trees. Tagging individual files is wasteful and results in quite a bit of extra complexity in https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/remote/merkletree/MerkleTreeComputer.java. We could specify that entries within a directory tagged with bazel_tool_input are also tool inputs, which would result in reusable Merkle subtrees independent of the tool/non-tool distinction. @benjaminp suggested that remote Actions could also gain a dedicated tool input root, but that change would need to go through the REAPI spec.

Happy to collaborate on any of this!

[armandomontanez]

cc @katre @jayconrod