Start adding some tests to Homu by testing the issue comment
command-parsing logic.

Take `parse_commands` and break it apart into two phases

* Parsing phase
* Execution phase

The parsing phase returns a list of commands with action names (ideally,
this would be a Rust enum, but to simulate that, we use action names on
a single class) that are returned regardless of the current state.  So
for example, `@bors retry` will return a `retry` command regardless of
the current state of `realtime`.

The execution phase then inspects the list of commands and decides what
to do with them. So for example, the `retry` command will be skipped if
`realtime == False`.

This has the positive result of having a parsing phase that has no
side-effects, which makes it much easier to test. This can lead to
higher confidence that the code works as expected without the high cost
of testing in production and possibly disrupting the build flow.

This has the negative result of adding a lot of lines of code to achieve
command parsing, which we already do successfully without the tests.

When parsing a @bors command, stop parsing when we reach any unknown
word. This enables commands like

    @bors retry (yielding priority to the rollup)

to include a description of why we retried (which gets put in the retry
log) without also setting `rollup`.

The only tricky bit to this is a command like

    @bors r=person 0123456789abcdef

where the commit sha is part of the `r=` command, and we need to parse
it that way.

Homu leaves self-approvals in comments, like

    <!-- @bors r=someone abcdef -->

and we need to make sure those still parse correctly.

Commands that started with the botname *and then a colon* were being
dropped, because the parser didn't recognize the command and didn't
continue. Fix this by explicitely allowing a colon after the botname.