Refactor vroom Failures to not be python Exceptions

[dbarnett]

The code currently raises vroom Failures as Exceptions, with a lot of code to catch, collect, and continue and potentially really weird behavior if there are mistakes in the code.

We should restructure the code so Failures are just normal return values from functions instead of raised Exceptions.

[martindemello]

the "railway oriented" design would be nice to use here (http://zohaib.me/railway-programming-pattern-in-elixir/ is a good writeup, e.g.)

[dbarnett]

The thrust of it (for python programmers, at least) seems to be to pass along an explicit state representing any errors, which is what I had in mind. The description sounds like error monads. The helper macros and stuff may not translate well into python, but we can try to keep concerns separated and at least have some strong conventions in the code.

[martindemello]

right, the attempts i've seen to implement an error monad directly in python end up looking rather ugly, but as a design strategy it seems to be the best way to do this. still trying to see if there's a way to do this in one small place and slowly expand it through the code, rather than do it all at once.

[dbarnett]

FYI, I found a bug related to us getting confused and passing an Exception type as a failure:

vroom/vroom/shell.py

Line 121 in f8b762c

failures.append(FakeShellNotWorking(errors))

I discovered this blows up if I do hit some error with the fake shell with errors about missing a FakeShellNotWorking.IsSignificant method, since it doesn't subclass Failure or define its own implementation of IsSignificant.