Policy for BC breaks and feature changes

[FelixJacobi]

I would like to introduce a formal policy for BC breaks to make the library more reliable for consumers. I would propose:

• Each change considered as a BC beak is only allowed in a major release.
• Upcoming BC breaks must trigger deprecation notices before/a deprecated component must be properly marked as deprecated before
• A new major version does not introduce new features compared to the previous version, but only introduces BC breaks or removes deprecated features.
• Parallel to a new major version, a new minor version of the previous major version is created, which can introduce new features. These both are identical except for deprecated features are removed from the new major version. E.g. 5.0 contains the same features as 4.4 (last version of the 4.x line) minus Deprecated Features plus BC Breaks like PHP version bumps.
  This allows consumers to update to the last minor version of the previous major version to check compatibility with the new major version (happy path by ensuring no deprecation notices are not thrown anymore).
  It also ensures that you can update safety to new major version, when you have no deprecation notices anymore, without changing anything else.

To consider what is meant with BC, we could use Our Backward Compatibility Promise (Symfony Docs) as a guideline to lean on. The proposal for release cycle is inspired from the one Symfony, which is one of the most predictable and transparent one: The Release Process (Symfony Docs)

[FelixJacobi]

I already started git branching of minor versions since 4.0. This allows to use that to organize the process without many efforts. You should always be able to merge upwards without much pain. Mostly PRs can just target master acting as the development branch. Only when moving to new major version, PRs explicitly introducing BC breaks or removing features and so being for the new major version must point to a different branch.