Problem: Many errors result from attempts to build commands which mighterror with a non-zero exit code. The failed commands are not displayedto the user, however.Solution: For every `([A-Za-z])Exit(Option<i32>)` error, change it to`\1Exit(Option<i32>, String)`, where the `String` contains the failedcommand. Format each `tokyo` command using `{:?}` and save it to thecorresponding error.Note that `Command` cannot be copied or cloned, and it's not possible toaccess a command's `std` field to get the underlying command, so weresort to putting the `Debug`-formatted command.

Problem: It's common to spawn a command and occasionally fail duringrunning the command or because it exited, leading to code repetition.Solution: Create a `command` module to abstract some of the boilerplateby wrapping `tokio::process::Command`. Create a `run` function thatabstracts most of this boilerplate.In some parts, the way commands are executed are a bit different, soinstead we leave them as it is.

Problem: The output when a command failed for deployment would show theerror message in the console output and _then_ the error message, whichwas confusing.Solution: Show the error message together with the error in an orderthat makes sense. This is done by capturing the output in the errormessage and printinting it in an exit error. We also use `Stdio::null`rather than `Stdio::piped` to avoid printing to the console.