When using "git cl patch -b branch_name issue_number" to resolve merge
conflicts in an uploaded CL the cherry-pick stage will probably fail due
to the expected merge conflicts. If you resolve the conflict and then
upload the now-merged CL you will actually create a new CL. This happens
because the SetIssue step is skipped when the cherry-pick fails.

This change sets the issue whenever a new branch is created. This is
safe (the new branch is not being used for anything else) and will
improve the situation in many cases.

crrev.com/c/2636593 is an example of a CL that was accidentally uploaded
as new when it was just supposed to be a resolving of merge conflicts on
an existing CL.

This change was manually tested with crrev.com/c/2107132.

Change-Id: Icb5b8e38feb6f0fa4a007d3924c4d69d2ee4937c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2638979
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Gavin Mak <gavinmak@google.com>