Track total number of merge conflicts when cherry picking PR from master branch to release branch #141819

Context: in the current github actions to auto apply cherry pick, we are not applying any resolution strategy when merge conflict happens. no resolution strategy was applied per previous discussions that we do not want to auto resolve and suggest wrong code to users.

We want to track the number of prs that would hit merge conflict when cherry picked from master to release. There are two ways to evaluate this metrics:

1. randomly pick PRs from master branch and cp them to release branch
2. when shipping releases, count the number of merge conflict PRs referenced in the cherry pick request

If using method 1 to collect this metric:
below are a list of PRs randomly selected from master branch that would hit merge conflict when cherry picked:

1. Run framework_tests_misc in arm64 and x64. #141797       sample merge conflict
2. hello_world app: migrate to Gradle Kotlin DSL #141541 merge conflict
3. Run some tests explicitly in both arm and x64. #141910 merge conflict
4. refactor asset bundle code to not depend on the global Cache.flutterRoot #142277 merge conflict
5. Fixed test in language_version_test.dart that failed when shuffling, … #142904 merge conflict

And here is a list of PRs randomly selected from master branch that would successfully create pull request:

1. Revise tooltip theme docs, including more cross-references #137316 automated workflow run. created pr
2. [flutter_tools] remove await runZonedGuarded() in tests #142336 automated workflow run created pr
3. Remove duplicate global declaration of UserMessages #142281 automated workflow run created pr
4. fix AppBar docs for backgroundColor & foregroundColor #142430 created pr
5. engine PR that succeeded Skip flaking test on Windows nobody is fixing. flutter-team-archive/engine#50401 created PR

Will keep updating the list when more data points become available (where the pr has a base commit newer than our merged commit)

Summary:
The merge conflicts as manifested in workflow runs align with the merge conflicts the pr would encounter if cherry picked through the terminal. and .ci.yaml changes seems to be the pr change that hit more conflicts than others.