Improve the Comment Capabilities in the GitHub API

[Cadair]

Despite #49 removing the main comment functionality of the bot, there are still many reasons why bots might want to post a status comment, and then edit it later. One of the motivations for #49 was that GitHub would happily send you three events (PR create, label and milestone) in very quick succession, so this proposes a way of mitigating this.

The API for this should be baldrick.github_api.IssueHandler.post_comment(unique=True) where it edits the comment if unique=True and there is already a comment.

Underneath there should be two things to mitigate multiple posts and guard against multiple pushes from GitHub.

1. We should restrict the bot to one comment per PR. This means we can use the GitHub timeline API to find the first comment posted by the bot, and always use that (irrespective of the content). This also means that if the bot accidentally multi-posts then only the first one will be edited and the rest can be removed.

2. There should be a in-memory comment cache of repo/pr number to comment ID which should prevent the race condition, as even if the comment is not available through the timeline API yet, the first comment that is posted will populate the cache and subsequent comment requests can use the cache to find the comment. When posting a comment to a PR if the cache is not available it should be reconstructed using the timeline API as described in point 1.

---

Bonus idea: Instead of limiting to one comment per PR, we could probably inject a UUID as a comment in the body of the text, which would be hidden in the web UI but we could search for when trying to find the comment to edit.