Lack of description on what the permissions on files in the input root are

(Note: This is a continuation of a remark I made in #40)

It seems to be the case that the protocol doesn't document what the permissions of files and directories in the input root are in relation to the credentials of the build action.

- Are build actions permitted to overwrite input files? When using Sandboxfs, this would be easy to achieve. Without using Sandboxfs, it's also possible, but has the downside that optimizations built around caching input files and hardlinking them is out of the question.
- Related to the previous question, is it permitted to hardlink input files to some other location? Recent versions of Linux have `fs.protected_hardlinks` enabled by default. This implies that if input files are read-only (due to the use of hardlinking caches), we cannot guarantee that the kernel will allow the creation of hardlinks to input files.
- In the general sense: is there even any guarantee that hardlinks can be created between two distinct directories in the input root? For example, may a worker place the output directories on a separate file system (`tmpfs`)? If so, this means you can't hardlink input files into an output directory.
- What are permissions on directories? Where may the build action create temporary files? In any directory in the input root, or only inside of a directory containing one or more outputs?

Buildbarn's workers don't use anything like FUSE (yet!), for the reason that I initially aimed at using Buildbarn on Kubernetes, where you can't simply make mounts inside of containers. After giving it enough tweaks, I eventually concluded that:

- All directories in the input root need to be writable to appease the build rules out there. Build rules should be allowed to rename and remove any file in the input root, and to create files in any directory in the input root.
- Input files may be read-only. They may be replaced by removing them first and creating a new one with the old name.
- Disallowing input files to be hardlinked (`fs.protected_hardlinks == 1`) causes a very small number of build rules to break, but those may be easy to fix.

Do we want to document this in the `.proto` file somewhere?

Start by reading issue #40 and the protocol's .proto definitions, then trace how the input root and build-action credentials are described. Resolve the listed permission and hardlink questions with the project maintainers, and consider the work done when the agreed semantics are documented in the appropriate protocol definition.

Written by the indexing model from the issue text.