Support BuildBox for local builds

BuildBox implements a FUSE filesystem to provide access to CAS contents without the staging overhead or danger of hardlinks. It will also abstract sandboxing across platforms. BuildBox is currently used in BuildGrid workers for remote execution.

Switching to BuildBox also for local builds will thus reduce build (staging) time and allows us to remove platform-specific sandboxing code from BuildStream.

Tasks

• Completely optional support for developers/testing, see !951 (merged)
• Support buildbox-run as sandboxing backend: #1177 (closed)
• Support workspace builds, depends on #985 (closed)
• Move sandboxing code from buildbox-fuse to buildbox-run-bubblewrap: BuildGrid/buildbox/buildbox-fuse#33 (closed). This depends on BuildGrid/buildbox/buildbox-casd#8 (closed)
• Support read-only rootfs, see https://gitlab.com/BuildStream/buildbox/issues/23 (also affects remote execution)
• Configurable sandbox UID/GID, depends on https://gitlab.com/BuildStream/buildbox/issues/26
• Consider potential issues due to CAS not storing timestamps (also affects remote execution)
• Check whether command exists in virtual root directory
• Support interactive mode for bst shell, depends on https://gitlab.com/BuildStream/buildbox/issues/27. Verify that job control works properly.
• Support network access with bst shell, depends on https://gitlab.com/BuildStream/buildbox/issues/25
• Update documentation to account for BuildBox as dependency
• Add BuildBox and dependencies to CI images
• Require virtual directory support for element plugins: #1262 (closed)
• Optimize output_directories in SandboxREAPI: #1223 (closed)
• Check for performance regressions
• Fix any remaining test failures (currently marked as xfail)