There is nothing in ArtifactCacheSpec that's actually specific to
artifacts, so I've made it a CAS class so we can use the same
spec for remote execution.

Since the artifact cache and remote execution share the same
local CAS store, they should share the same CASCache object. Moving
this into context allows us to do this.

Uses the new config options introduced earlier to specify remote
exec storage and execution service.

Tests that we get a sensible error message when we specify incomplete
or wrong information in the configuration for remote execution.

The port number must come after the hostname and before the path.
The path is ignored by CASCache anyway, so including it is misleading.

Split remote execution from artifact cache

Closes #750

See merge request !946

i.e. with a given directory and filename, check parent directories until
either a directory with the filename is found, or you reach the root of
the filesystem.

WorkspaceProject contains all the information needed to refer back to a
project from its workspace (currently this is the project path and the
element used to create this workspace)

This is stored within a WorkspaceProjectCache object, which keeps
WorkspaceProjects around so they don't need to be loaded from disk
repeatedly.

Searching for the workspace file is preferred to searching for the
project file for the moment, because it avoids the circumstance of
the workspaces being inside a directory where a higher-level directory
may have project.conf (but may not be a buildstream project).

cli: Interactively warn if the user is trying to close the workspace they're using to load the project

This involves changes in:
* _stream.py:
  * Add the helper Stream.workspace_is_required()
* userconfig.yaml:
  * Add a default value for prompt.really-workspace-close-project-inaccessible
* _context.py:
  * Load the prompt 'really-workspace-close-project-inaccessible' from
    user config.
* cli.py:
  * If buildstream is invoked interactively, prompt the user to confirm
    that they want to close the workspace they're using to load this
    project.

Known issues:
* `bst shell` works, but `bst shell COMMANDS...` doesn't, because click
  has no way of separating optional args from variable-length args.
* `bst checkout`'s usage string marks LOCATION as an optional argument.
  Because click gets confused if there's an optional argument before a
  mandatory argument, I had to mark LOCATION as optional internally.
* `bst workspace open` makes no sense with element being optional, so
  I skipped it.
* `bst workspace close` will probably need to be revisited when multiple
  projects can own one workspace.
* `bst workspace reset` will happily delete the directory you're
  currently in, requiring you to `cd $PWD` to see the contents of your
  directory.
  I could exclude the top-level directory of the workspace being
  deleted, but it is entirely valid to run workspace commands from deeper
  in the workspace.
* `bst source-bundle` does not work if a workspace is open at all, and
  according to #672 is scoped for deprecation, so I have left it alone.

Note: This omits tests of `bst shell` because a command-line can't be
passed without also specifying an element.