UPDATE: to cherry-pick, please apply both the original fix and this followup fix.

With our current flutter release revamp, we intend to empty merge back to master from every release branch cherry-pick and then have flutter upgrade always fast forward. However, this would severely limit the choices of which release to promote to a branch if said branch had a cherry pick late in its life cycle. Consider:

I   <- HEAD of master
|
H   <- empty merge beta into master
|\
| G <- beta cherry pick of F 1.0.0-0.1.pre, HEAD of beta branch
| |
F | <- fix for A
| |
E | <- regression
| |
D | <- dev release 1.1.0-0.0.pre, candidate for next beta
| |
C | <- important feature desired for next beta release
|/
B   <- dev & beta release 1.0.0-0.0.pre
|
A   <- regression

In this situation, where commit G is a cherry pick onto the beta branch, and H is the subsequent merge to master, the next beta release would have to be (or be branched from) a commit that appears AFTER H in the master branch, or else users on commit G would not be able to fast forward to the next beta version. However, picking a commit after H would mean also picking up the regression in E. In this situation we would like to have the freedom to promote commit D to the next beta (which would require an additional cherrypick of F).

Thus, we should restore support in flutter upgrade for non-fast-forward upgrades.