[Releasing] rethinking branching again

[Oswald Buddenhagen]

so, the 5.4 branching went technically (almost) as planned.
what went wrong again is of course ... ehm ... let's call it "wiggle
room".
as i (as an executive force of RM) don't feel like dealing with these
issues each time, i'd like to propose yet another modification to the
branch creation process. the idea was brought up by olivier:

- the branch is created one week _before_ the feature freeze, from
  whichever state dev is in
- at the announced date of the freeze, we do a downmerge dev -> new
  branch, also from whichever state dev is in

this has the following features:
- as the branch exists early, people can start submitting their "must
  have" changes there early. this is also the time to obtain freeze
  excemptions for "epic" changes that are running late, and having them
  retargeted.
- as the "branching window" is naturally long, there is almost no risk
  that cherry-picking would be necessary due to somebody missing it
- therefore there is also no need for a lockdown on dev, which means
  that nobody can complain about being held up by unrelated release work
- RM doesn't need to pay attention to any freeze excemption quibbles,
  because people really have enough time to sort it out with their
  reviewers and maintainers.
- the final downmerge is expected to be rather unproblematic (wholly
  unlike the former dev -> stable downmerge), as the branch (and its
  integration setup) was created only shortly before.
- of course this has the unfortunate effect that branching (RM task)
  again involves a dev task (merging), but whatever.

in principle, that model seems applicable to release branch creation as
well, so we can already try it on 5.4.0 (possibly with a shorter window
than a week - maybe three days).

anything fundamentally wrong with the idea?