The introduction of review request ownership changes made counters a bit
more complex, and for a time broke our outgoing counters. This was
largely addressed in commit abc032d20f3b286fb193df4a60340cf6dba8daa6,
but there was an edge case being hit by some users.

If a new owner's `LocalSiteProfile` didn't yet exist at the time they
were made the owner (such as if they had just been added to a
`LocalSite` but hadn't logged in yet, or were added by way of an auth
backend), then the initial values for their new profile's counters would
already be computed when fetched in `_update_counts()`, based on the
newly-published draft changes (which would include the ownership change,
and possibly reviewer changes). The outgoing counters would be worked
around from the previous fix, but incoming counters could be broken.

The same problems can also occur even without ownership changes, if the
user had created a review request and published via the API or some
other form of automation but hadn't yet logged in or triggered a code
path creating an initial profile.

This is hard to work around if the profile is being created in
`_update_counts()`, but the solution is pretty easy. We now ensure we've
fetched/created a profile before any part of the draft gets published,
giving us stable counters to work with as part of the publish and update
steps.

This fix lets us remove a bunch of special-cased updates in the previous
fix, and will take care of the various edge cases all at once.

Unit tests and docs have been enhanced to help us better reason about
these counters in the future.

Testing Done:
Unit tests pass.

Reviewed at https://reviews.reviewboard.org/r/10721/