Is your feature request related to a problem? Please describe.
release-please currently expects all your release commits to be on the same branch you are releasing from. This doesn't work when you have multiple, long-lived release branches.

Our release process works as follows:

• We work off main
• When it's time to release a new version (major or minor) we create a branch off main at the feature-set we want to release
• Bug-fixes and security patches for release versions are later cherry-picked into these "release" branches (after being committed to main)

We are usually supporting at least the last 2 minors with patch releases. Using the --target-branch feature of release-please, we are able to release from these release branches, but since the release tags are on a commit on theses branches (which is desired), future releases on other branches can't find them. As a result, release-please doesn't find the correct previous release sha to compare to.

Describe the solution you'd like
I'd like an option, like --consider-all-branches that when specified, does not limit the search of commits for released shas to the current branch. Of course, we don't want to look at every commit ever in the repo, so in this flow I suggest release please uses github's graphql api for comparing commits between two shas.

Describe alternatives you've considered
I tried writing a custom GitHub action that brought in a lot of release-please code as a library, but that was a much more code to maintain than the changes necessary in release-please to support them.

Additional context
I have an initial solution that I will PR after creating this issue. It's a draft at the moment, as it needs some testing, but I want to get buy in on the approach before investing more time.