let miq_bot merge

Sometimes PRs get merged and they break master. I guess this is due to a race condition, like when travis ran, everything was good but meanwhile another PR got merged which would let the former PR fail. The person about to merge the first PR still sees the old green travis and happily merges.

Let miq_bot do the work.

1. label a PR with [merge] or address miq-bot with a merge command (permissions apply)
2. miq-bot queues PR up for merging, so no merging in parallel
3. if travis is green: merge via github api

the downside: We can only be as fast as our test suite. Now it runs ~30mins, so we would get 2 merges / hour.

Some think, having a straight git history is nice. Although thats opinonated, I guess:
https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/
In case we want that:

1. pull PR into miq-bots repo hub checkout https://github.com/github/hub/pull/134
2. rebase PR ff-only
3. run travis against miq-bots PR
4. in case travis is green: merge miq-bots PR

I guess the former part would be pretty easy to build and would mainly rely on discipline not to hit the big green button 🔲
I'd be happy to implement that if we want to do this.

In the future we could even run a larger test suite on the merge queue (eg. some of QEs automated tests).

@Fryguy what do you think? And please pull in those to whom it may concern :)

Start by reviewing the GitHub API, Travis flow, and miq-bot repository workflow described in the issue. Define the merge queue and permission behavior, then verify that queued PRs are merged serially only after Travis is green; the issue also outlines an optional rebase and fast-forward path.