Think about package ecosystem

[moodymudskipper]

Since :

• we're probably not going to convince every class owner to build their own constructors
• extending for every class in this repo is a bit messy, ggplot2 takes already too much room
• An ecosystem means separate issue trackers/options for watchers, better structured code, better structured tests, potentially different maintainers, separate news and versions...
• We can more systematically make sure a specific package maintains constructors for all classes of the package

We have 3 parts in this package :

• the bare bones : exported functions and helpers, generics
• the extension helpers, start with ".cstr" not to bug users
• methods and opts_ functions

I think a first step would be to have {constructive.tools} and {constructive.methods}.

• {constructive.tools} for bare bones and extension helpers
• {constructive.methods} for all methods and opts_ functions
• {constructive} imports both, and re-exports {constructive.tools} functions, except extension helpers (minor breaking change)

Then we can move some methods from {constructive.methods} to other packages like {constructive.base}, {constructive.ggplot2} or {constructive.tidyverse}, and either {constructive.methods} or {constructive} imports them and reexports opts_ functions.