In order for the freshly minted keep-test-eth-faucet Heimdall script to
run we need web3 commands available.  Here we install that package.

We run a handful of internal ethereum chains, they're a pain in the ass
to fund accounts on.  You have to use the geth console, or geth CLI to
transfer eth.  Our keep-test environment has a public transaction node.
This means we can take advantage of Heimdall to fund accounts on this
chain, instead of having to use the aforementioned methods.  Here we
provide a very basic Heimdall command that funds a passed account with
10 eth.

Can go either way really...but we need to whole-ass whichever way that
is.

Rather than peg the script to an environment we're making the naming
generic, with a note that the script only works for keep-test at the
moment.  This is to set the intention that we should be able to use this
script for multiple environments, it just needs to be extended.

We were using mixed mode variable expansion in strings, I updated the
one outlier to match the rest of the script.  Also added a note that
this script only works with keep-test at the moment.

Eventually we'll be able to pass an environment as an argument to this
command.  For now we shorten and make the faucet invocation command
generic, as it should be.

Frankly I'm not sure why we can do this.  In previous experience you had
to use async/await all the way up the path, else you would run into
runtime errors regarding using await in a non-async function.

It's a bit unnecessary from the perspective of the person being funded.
They don't care where the ETH comes from, and we as operators know who
the purse is.

In an effor to enforce ordering we wrap the msg.send calls for await
results in then.  This seems to work, however it produces a new scenario
where then then log is returned before the msg.send message that should
fire BEFORE the await.  Need to look closer.

we need to exit on catch, adding a return so that if we catch we don't
try to continue the script.

The "account" in this case is the purse.  We should clarify that this
password is for the purse, not just an eth account.

tl;dr here is that we think the ordering issues on Flowdock are due to
the fact that the unlocked and funding msg.sends are firing at about
the same time, and that Flowdock doesn't guarantee ordering in that
case.  We're just going to go ahead and remove the unlocked log, as this
falls over if the accounnt isn't unlocked anyway (and we have logging
for that).

Needed to update the usage comment after shortening the command.  This
also includes changes made by prettier.