Since the SandboxDummy sandbox is only used in very specific
circumstances and with good reason, this adjusts the SandboxDummy
class to take a reason and to return it if `.run()` has to
raise an exception because this is a dummy sandbox.

Signed-off-by: Daniel Silverstone <daniel.silverstone@codethink.co.uk>

Since Darwin is limited to the dummy sandbox for now due to OSXFUSE
being unsupported as yet, and there being no suitable sandboxing option
for use on OSX, give this as the reason so that it can be reported if
the user attempts a local build.

Signed-off-by: Daniel Silverstone <daniel.silverstone@codethink.co.uk>

To better report issues in the absence of a suitable bwrap, or the
FUSE devices, this refactors the checks for sandboxing in the Linux
platform to cover the various possibilities.  The reasons are then
collated and passed to the dummy sandbox for later reporting to the
user if a local build is attempted.

Signed-off-by: Daniel Silverstone <daniel.silverstone@codethink.co.uk>

On some potentially broken systems, running `bwrap --version` might
fail with an error code.  This patch corrects the oversight ensuring
that we cleanly return False for version checking in such cases.

Signed-off-by: Daniel Silverstone <daniel.silverstone@codethink.co.uk>

Instead of an if/else ladder which is quite complex, this patch
uses the fact that Python supports by-component tuple comparison
to simply compare two (major, minor, patch) tuples

Signed-off-by: Daniel Silverstone <daniel.silverstone@codethink.co.uk>

Since there are use-cases where BuildStream could be installed
onto systems which do not have BubbleWrap (e.g. for remote-build-only
scenarios) it is not correct to assert a dependency on bwrap during
installation.  This patch makes the assertion a warning, and also
clarifies the message somewhat.  This should fix #644

Signed-off-by: Daniel Silverstone <daniel.silverstone@codethink.co.uk>

Make bwrap check runtime only

Closes #644

See merge request !847