Allow project relative workspace paths

[See original issue on GitLab](https://gitlab.com/BuildStream/buildstream/-/issues/191)
In GitLab by [[Gitlab user @tristanvb]](https://gitlab.com/tristanvb) on Jan 15, 2018, 07:04

While I find this to be a very odd practice that I would not recommend, it seems that people like to open workspace directories as subdirectories of the BuildStream project itself.

The one benefit I can see to this is that if the workspace is a project relative subdirectory; then one could move the project to a new directory and carry the workspace along with it as a subdirectory.

But for this to work without breaking the workspace/project relationship, BuildStream would have to support serializing and interpreting the workspace directory as a project relative path.

To make this work:
* `bst workspace open` must check if the specified path is a subdirectory of the project
* If this is the case, then we can avoid calling `os.path.abspath()` here
* When interpreting a workspace directory loaded from the project state directory (`project/.bst/...`), we should be initially using `os.path.join(project_directory, workspace_directory)`; this can be done without consideration of whether the path was initially relative or absolute, due to the behavior of `os.path.join()`

Update by [[Gitlab user @toscalix]](https://gitlab.com/toscalix) : a [proposal](https://mail.gnome.org/archives/buildstream-list/2018-August/msg00078.html) that covers this case has been sent to the mailing list.

Start with the `bst workspace open` path handling and the workspace data loaded from the project state directory (`project/.bst/...`). Trace how workspace paths are serialized and interpreted, including project-relative subdirectories, then verify that moving a project with its workspace preserves the relationship. The issue also links to a mailing-list proposal that may define the intended behavior.

Written by the indexing model from the issue text.