POC: Boilerplate functions

[teunbrand]

This PR aims to (eventually) fix #6142.

Briefly, it introduces boilerplate() that can take in a ggproto class and spit out a constructor.

This PR is a proof-of-concept because it probably merits some discussion whether we would like to go down this road. As such, the PR only implements boilerplate() for Geoms, but can be expanded in the future for Stats and Scales as well, I think.
The boilerplate() function is used for amenable functions, but not more complex ones. For example, geom_text() or geom_boxplot() perform input checking that we cannot currently easily fit into the boilerplate code.

A few notes about the PR:

• Because we apply this function for suitable geoms, we had to swap the position of class definition and constructor, as boilerplate() takes the class as input. These are the largest diffs.
• Some order of arguments are changed, as they are now handled consistently.
• Many geoms had 'hidden' parameters, i.e. parameters like lineend that would be accepted by the Geom$draw_panel/group() method, but were set as arguments to the constructor. These are now all exposed.
• In visual tests, I had to accept the changes because draw_key_polygon() now actually gets the line settings (lineend, linejoin, linemitre) from the geom instead of having to default these.
• I don't have a lot of experience of programatically constructing function bodies. If there is a better way, I'd gladly accept pointers.

[yjunechoe]

I'm super excited to see this develop! (esp. for Stats!)

programatically constructing function bodies

I don't have a perfect solution (not thoroughly tested beyond the example) but I thought I'd just throw in some ideas for that, in case the PR will eventually need to do this before it's ready to merge. (I only looked at constructing the layer() expression - check feels complicated at a more fundamental level?)

[yjunechoe]

Thanks for considering my suggestions! Following up w/ just 2 more things I noticed

[mjskay]

FWIW, very excited to see something like this happen! {ggdist} has its own boilerplate generation for geoms and stats if you are looking for a comparison point: https://github.com/mjskay/ggdist/blob/master/R/abstract_geom.R

Besides reducing maintenance issues I have also moved a lot of documentation into it, so now comprehensive docs of aesthetics and computed variables are generated automatically. Has made my life quite a bit easier.

[teunbrand]

Thanks Matthew, it is cool to see that other people have also run into (and solved!) 'there should be hidden parameters' problem I got stuck on as well ^_^ It is interesting (in the good way) to see you opted for a ggproto approach, but I guess this might help coordinate various tasks at once.

I also recently was pointed to @corybrunson's https://github.com/corybrunson/ordr/blob/main/build-pre/build-layers.r, which performs a similar task as well.

[mjskay]

Heh oh yeah, I also see your other PR landing on a very similar default_params solution to extra_params as well. I had to fix that because it made it very hard to create a class hierarchy of geoms without constantly copying a bunch of boilerplate param definitions across geoms.

If this gets combined with other changes, depending on how far that goes in the direction of breaking changes (including the potential for introducing breaking changes to solve other longstanding problems), one solution you might consider is introducing an alternative base Geom class people could inherit from to "opt in" to the newer, cleaner interface.