Initial infrastructure for editions

[teunbrand]

This PR aims to adress a topic discussed by Thomas and me off-github.

Briefly, we'd like to bring edition structure to ggplot2 to opt-in otherwise backward incompatible changes. It is modelled after testthat, with a few adaptations. This PR just aims to introduce infrastructure for working with editions in ggplot2.

The most important difference with testthat is in the relation that it has to other packages. The testthat package has 1:1 relationships: the tests of one single package does not affect tests in a second package. In contrast, it is not unreasonable to assume that for example {extensionPkg} defines ggplot2 extensions, which are then subsequently used by wrappers in {wrapperPkg}. In this example {extensionPkg} and {wrapperPkg} might opt-in different editions, which needs to be facilitated. For this reason, this PR gives each package their own local edition.

This PR is currently marked WIP as some details need to be ironed out. Specifically:

• How do we expect maintainers of reverse dependencies to interact with the edition system?
• How do we expect users to interact with the edition system?
• What type of things do we want to edition?

[teunbrand]

Add a few example cases to edition

[teunbrand]

To answer some of the questions:

How do we expect maintainers of reverse dependencies to interact with the edition system?

I think we expect maintainers to:

• Opt-in the 2025 edition by setting a 'Config/ggplot2/edition' value in their DESCRIPTION file.
• Use edition_require() whenever implementing features that rely on new editions.
• Use edition_deprecate() whenever they want to deprecate something along with ggplot2 editions.

How do we expect users to interact with the edition system?

I don't have a full answer yet. Currently they can use local_edition(2025) to opt-in newer features. I think it would be neat if we can have regular users opt-out of the 2025 edition while having packages opt-in, but this seems counterintuitive to implement.