Since gm_get_motion_vector is trying to give a motion vector for
"the frame as a whole", it makes more sense for it to calculate
the motion of the *center* of the block rather than the top-left
corner of the frame.

In theory, this change should also help the encoder make better
decisions on when to use global motion. It avoids an issue
where, early in the frame, NEARESTMV looks like a good way to use
the global motion vector *without* paying the rate cost applied
to the first few global motion blocks in each frame. This seems
to lead to a better overall result.

Change-Id: Ia5c6259ceb8b4ff3d00a5d553e1d18bdb802da59