lint: have git-subtree-check warn about backportability #35686

A subtree update PR is easier to backport when its merge commit is stacked on the previous subtree merge instead of on master.

Have git-subtree-check.sh warn when the latest subtree merge does not follow that structure. This is not always practical, so it's a warning, not a failure.

Example without warning:

test/lint/git-subtree-check.sh src/ipc/libmultiprocess 66b4e30e

Example with warning:
test/lint/git-subtree-check.sh src/ipc/libmultiprocess 02afa661
```sh

The check only runs when the commit (`COMMIT`, or `HEAD`) is the subtree merge itself. Since CI performs a merge with master, it skips this check.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35686.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

I'm not sure. We sometimes cherry-pick commits from the subtree if they contain fixes that need backporting. Is this really solving a problem?

In some rare cases it is required to adjust the code for the subtree bump in the merge commit itself (to avoid build failures on the merge commit itself), so that would warn in that case and somehow encourage build failures?

Also, can you explain how this simplifies "backport"? IIUC you are referring to merging the subtree merge commit as-is into several branches? I think this is nice, and good to keep in mind, but the alternative of having a second similar subtree merge (with only the commit id different) on the backport branch is also fine and harmless?

you are referring to merging the subtree merge commit as-is into several branches? I think this is nice, and good to keep in mind

Yes, we've done this a few times for libmultiprocess: #34804 and #34952 have the exact same merge commit hash, making the pack-port trivial to review.

And it was specifically suggested here: #33439 (comment)

For future releases (31.x and later) we could base new subtree updates on previous subtree updates instead of on newer master commits.