change in github workflow!

[Martin Nowak via Digitalmars-d]

We replace the old cherry-pick approach by introducing stable branches,
more info here http://wiki.dlang.org/DIP75#Branching_strategy.

This avoids having to manually identify bugfixes to be cherry-picked
into the release branch (2.067.0 is missing at least 2 fixes) and helps
us to do point releases.
Also merging instead of copying commits allows to reliably identify
which releases contain a certain fix.

>From now on, any pull request to fix a regression or an important bug
should target the stable branch instead of master. Changes on stable
should be as low-risk as possible, be backward compatible, and avoid
adding deprecations.
Unfortunately github doesn't allow to retarget pull requests, so if a
pull targets the wrong branch, it needs to be reopened.

We'll soon reconfigure the auto-tester to test stable as well.

-Martin