The SCMClients had some confusing responsibilities where they attempted

to handle the guessed summary/description logic in the diff methods,

getting and setting data in the options object. This logic had no

business being in the diff method, or in SCMClients for that matter, and

should have exclusively been in rbt post.
On top of that, we had some variations in how the commit summary and

description were fetched and processed in the different SCMClients. This

led to differences in behavior and subtle bugs. For example, Mercurial

was grabbing the summary from the wrong end of a commit range, and

Bazaar was providing extraneous information for the descriptions.
Now, instead of extract_summary() and extract_description() methods,

SCMClients only need to implement get_raw_commit_message(). This returns

the full set of commit messages for the provided revisions. The base

SCMClient class then provides a get_commit_message() that calls that and

splits the result into a summary and a description.
The description also no longer includes the summary line, preventing the

first line of the Description field from mirroring the Summary field

unnecessarily.
rbt post is then responsible for calling this when it needs to generate

the guessed content or match an existing review request in order to

update it.
Since both get_commit_message() and diff() need parsed revisions, it no

longer makes sense for diff() to call parse_revision_spec(). That's now

the job of the caller, which results in diff() being just a bit simpler.
At this point, the get_diff() utility function is no longer necessary

either, so it's been removed.
Now that rbt post owns more of the logic, it can also be smarter about

when things are called. Previously, if using -u, we'd parse the

revision spec twice (once in diff() and once when generating the

summary/description for matching).
We also would make at least two calls to get the summary and description

(more, if using -g and the description was blank).
rbt post now caches the parsed revision spec, and the commit message,

preventing us from having to run as many costly commands.
This all results in a cleaner design with less responsibility in

SCMClient, fewer usages of the options object, and faster posting.

Posted an update to this change using -g -r. Then followed it up

with additional updates as I tweaked some comments, using -u and

-g -u.
Tested posting with -g on Bazaar, Git and Mercurial in the following scenarios:

Single line summary.
Multi-line summary.
Single line summary + blank line + description

In the first two, the whole commit message was used for the description.

For the third, only the description was used.
Tested posting updates to changes using -u on Bazaar, Git and Mercurial.
Tested also with -g -u.
Unit tests passed. Discovered while updating tests that Mercurial's summary

guessing read from the wrong end of a commit range, and fixed that. Verified

by hand.
No errors or warnings from PyFlakes.