Leveraging --rebase-merges --update-refs mechanism to rebase several branches in one run

[Yann Dirson <ydirson@free.fr>]

This idea comes from a repo[1] where I am experimenting with code variants:
on one side I have a branch where I add to the core mechanisms, and on the
other(s) I have several branches where I experiment with different rendering
options.

There are indeed 2 different workflows here:
- improving the variants themselves, where occasionally some fixup or new
  commit for the core branch gets introduced
- adding feature to the core branch, then merging that into each variant,
  where fixups already appear quite regularly

That produces a set closely-related branches with lots of merges, and applying
the fixups is a bit tricky.

The "core + 1 variant" case pretty much works out of the box, with --rebase-merges
and --update-refs generating a perfect instructions sheet.

But if I was to rebase just one variant while rewriting the core branch, obviously
all other variants would still fork off the pre-rewrite core branch, and we'd loose
all chances of automating the same work on the other variants.

OTOH, if I get `git-rebase` to generate the instruction sheets for those other
variants first, strip them (manually) from the common part, and insert them in the
instruction sheet of my "core + 1 variant" case ... I do get the whole of my branches
rebased together, and sharing the updated core.


So the question is, would there be any obstacles to let git-rebase automate this
completely?  By chance it could even be a trivial change?
I guess we'd only want this feature to be enabled under certain conditions, like
--update-refs being specified so the many heads of the rebase would be reachable.


[1] https://github.com/ydirson/test-yew-tutorial/tree/opr is the "core" branch,
and branches opr-* are the variants