BuildStream doesn't behave correctly with assertions disabled

BuildStream was written with the assumption that assert statements are always enabled, but now we know it can be common practice in some production environments to disable assertions in python code.

The result is that running with assertions disabled is not really that safe.

Currently we have two failure modes:

• A fatal error occurred

  This can mean we had a system error, unable to allocate some resource, or it can mean that the user has provided invalid input, for instance a malformed YAML file or such.

  In all of these cases, we raise an error which derives from BstError, and the user gets an end user targetted error message explaining the problem and hopefully providing some recourse for the user to fix it.

  If these kind of errors are untrapped, they can bubble up as stack traces, but that is a bug and really should never happen.

• A programming error occurred

  This can mean that we end up in some state that we are unsure how we ended up there, but we know it is invalid, for instance when trying to checkout an artifact and the cache key doesnt exist.

  It can also mean that there is a bug in a plugin somewhere, in which case we always want to present the user with a full stack trace; as this is more helpful for solving bugs. For the end user, this will show up as a BUG message in the UI.

  These are all currently implemented with assert statements.

Since python programmers typically have a different expectation about assertions, such that they can be disabled at runtime and that the assertions are only used for debugging, it could make sense to create a new Bug() exception which derives directly from Exception, and replace our current assert statements with raise Bug(...) statements.

This might allow us to use assertions more vigorously, for instance to assert the validity of function arguments at every function entry point, and allow disabling the assertions at runtime, this would conform more to pythonic expectations.