WIP: DT-682: Fixes #3811: Failing commands throw exception by default.

[danepowell]

Fixes #3811

I'm not sure about this approach as it requires a lot of refactoring, and will almost certainly cause at least minor regressions.

To recap the problem, Robo's CommandStack doesn't throw any exceptions if a command (drush, composer, etc...) returns a non-zero exit code. It just captures and returns the error code. So every time BLT calls a command, it has to manually check and handle the exit code. This has led to many bugs in the past where exit codes are not checked and BLT doesn't throw an error as expected.

This "fixes" that by overriding all of Robo's built-in tasks to throw an exception if the task fails.

In terms of regressions, the biggest risk with this change comes from the fact that commands will now throw an exception and stop the process by default when they fail, unless you specifically wrap them in a try/catch (duh, this is the whole point). I know that there are some commands that we run (such as drush cr) that we don't really mind if they fail, now they are going to start halting unexpectedly. Plus, it's just a big change with lots of unknown side effects.

In terms of refactoring/code complexity, this requires that we override every Robo task individually. It generally just goes against the way Robo is architected. And because of this, it won't help if in the future someone uses a Robo task that we haven't yet overridden. The whole point of this user story is to make commands strictly handle errors universally, so in that regard this approach still falls short.

Ideally Robo would fix this upstream and save us all this trouble: consolidation/robo#891. Maybe I'll ping the maintainer. As a short-term solution that's much less effort, we could just perform a code audit to try to catch any other instances where we aren't checking exit codes, and perform spot-fixes instead of changing the entire architecture.