Change cherry-pick bot to waterfall changes down from newer to older branches

At present, cherry-pick bot performs all possible cherry-picks simultaneously. The upside of this is faster propagation of important fixes to all targeted branches, but it carries a risk of regression as well.

For example, A cherry-pick from dev to 6.x, and 6.x.0 could experience a regression if the .0 pick is successfully merged, but the fix to the main branch 6.x is not merged until after the next branching event. The fix would then be present in 6.x.0 and 6.x.2, but not 6.x.1.

Proposed new workflow would queue staging of cherry-picks such that changes are merged from newest to oldest feature branches.

• For example, if a change on dev would have pick targets of 6.5, 6.4, 6.3, then the bot should pick to 6.5 immediately, but leave the 6.4 and 6.3 pick targets intact on the resulting cherry-pick such that the change waterfalls down to 6.3 eventually.
• If a change has release branch pick targets such as 6.5, 6.5.0, the change should pick to the main branch first and then the release target.
  • It is possible that a gap may appear if a branching event occurs before the main branch target is merged such that 6.5.1 in the example is missed. The bot may need to detect this gap and auto-pick accordingly when picking to other specified release-branches.