Temporary branch for API changes

[longfin]

See also: #2440

Recently we're working for reorganize action evaluation logic, and it causes many breaking API changes that should be resolved from the application codes (e.g., Lib9c, NineChronicles.Headless).
Basically, these changes were merged into the main branch and then tweaked on the app after release, but with so many of these changes, I have a concern that the release itself might be delayed since main isn't ready for apps.

To temporarily alleviate this, instead of merging PRs requesting API changes directly into the main branch, �I suggest putting them in a temporary branch and merging them into the main after preparing app-side changes.

[riemannulus]

Agree to prepare app-side changes first.

[longfin]

On second thought, even if we agree about app change preparation before release, ad-hoc branching might be overkill for every situations since some changes might be quite simple.

So, requiring app-side API changes per PR (before merge), instead of this ad-hoc branch strategy might be better at this moment.

[longfin]

I added "Breaking Change" label. PRs by @planetarium/engineers with this label would be encouraged to contain migration PR on the application side (i.e., Lib9c, NineChronicles, NineChronicles.Headless).