Separate storing commit IDs and updating from them.
Review requests previously stored commit IDs and allowed setting them

during creation with the assumption being that they were intended for

setting the review request information and diff.
This change removes that assumption. Commit IDs can now be set on new

review requests or updated later on drafts. The old behavior is invoked

by passing a commit_id in the request along with create_from_commit_id=1

or update_from_commit_id=1 (depending on the operation). For

compatibility reasons, setting changenum will automatically trigger the

old behavior as well.
Since commit IDs are now stored along with drafts, we now record them in

change descriptions as well. Some changes needed to be made to field

recording logic for this. I also split up the existing CommitField

into ChangeField and CommitField in order to better separate out

responsibilities and provide a more appropriate label depending on

whether Perforce-style changesets are used vs. commit IDs.
This does remove the ability to update based on a commit ID using

HTTP PUT on the review request item resource, in favor of the draft API.

JavaScript and Python unit tests passed.
Posted an exiting commit using the New Review Request UI. Saw the commit

information in the draft, plus the summary, description, and diff.

Published and saw the commit information remain.
Updated RBTools to post the commit ID, and posted a new branch. It didn't

try to grab the review request info or diff from the server, but rather used

what I had. Saw the commit ID in the draft. Published it, then made a change

locally and posted again. Commit ID changed. Published, and saw the change

entry for the commit ID.
Posted a change on a Perforce repository using rbt post.

Saw the "Change:" field instead of the "Commit:" field. Published.

Posted an update with the same command, and it successfully reused and

updated my review request.