`bst shell` should be able to stage the specified element on top of a base element

[See original issue on GitLab](https://gitlab.com/BuildStream/buildstream/-/issues/422)
In GitLab by [[Gitlab user @tlater]](https://gitlab.com/tlater) on Jun 12, 2018, 12:32

## Background

[//]: # (Provide a background or the root/source that justifies this task or action.)

I find that I avoid using `type: runtime` on very low-level elements most of the time, even if they are technically runtime dependencies. This is because they tend to be large and contain dependencies mostly available on systems I'll want to deploy software to. It doesn't seem useful for `bst checkout` to checkout something like `/bin/sh`, for example.

This works for anything I want to run in CI, or actually use for deployable builds, but as soon as I start developing I want to run `bst shell` on whatever I am working on.

`bst shell` currently requires the runtime of any element I want to shell into to contain a `/bin/sh`, and therefore consistently breaks unless I add `type: runtime` to my base platform dependency. As a result I end up constantly adding and removing dependencies for debugging.

There *is* `bst shell --sysroot`, but it requires a checkout of the base platform, which makes it cumbersome to use for debugging. It also doesn't update with potential changes to the base platform, which makes it feel wrong for this use case.

## Acceptance Criteria

[//]: # (Acceptance criteria should follow the S.M.A.R.T. principle https://en.wikipedia.org/wiki/SMART_criteria )

We should have a way to avoid specifying `type: runtime` on base platforms with `bst shell`. Options include:

- Adding a `--platform` option which specifies a dependency to stage the given element on top of
- Allow specifying multiple elements

This is still very up for discussion, please do comment :)

**Update from Laurence, February 2019:** This was discussed at the Gathering in Jan 2019 and a [summary mail](https://mail.gnome.org/archives/buildstream-list/2019-February/msg00001.html) sent to the list which was discussed a little.

## Update

This is to be handled simply by allowing multiple elements to be specified to `bst shell`, allowing one to stage multiple things. For the case of `bst shell --build`, it is easy enough to consider the first specified element to be _"the build element"_, as mentioned elsewhere in the comments below, there can only be one build environment.

A note about CLI consistency, is that this is much the same issue as #771, and should be handled the same way.

Allowing multiple targets being specified here will not cause breakage in the CLI api, and as such we will not be blocking on this for the 2.0 milestone.