We had a regression a few releases ago where change numbers/commit IDs
were being stored solely on a draft and not on a review request,
preventing those change numbers/commit IDs from being returned in
conflict error responses or matching properly when posting a change for
review.

This was largely a problem with Perforce. The workflow for Perforce is
to use RBTools to post a change number. If that change number is already
posted, the review request matching it is returned, and RBTools then
extracts the change number for use in subsequent requests. However, this
was no longer being set on the review request, so it was coming back as
a null value.

We now always set this on the review request itself, updating both the
commit ID and the change number. This happens on the initial save,
before we even try to update the draft based on that commit ID/change
number. This value is still cleared as expected when discarding the
review request.

Tested manually and verified that posting a change for review using

an existing change number now updates the correct review request again.

Verified it was broken before.
Tested manually that Perforce changes show "pending" when the change is

pending, and don't when it's not, fixing bug #4484.
Unit tests pass.