Add support for tidybayes fitted_draws and posterior_draws

[gavinsimpson]

This came up in mjskay/tidybayes#130

Now that simulate.gam and related methods in gratia do the correct thing, I should revisit this.

@mjskay I follow what structures/layout/naming conventions are needed to support this, but was the intention that I include gratia:::fitted_draws.gam and gratia:::predicted_draws.gam or that I'd have some functions that provide equivalent output that you can wrap in tidybayes?

Either is fine with me.

[mjskay]

Ah, good question. I think there are pros and cons either way...

Pros / cons of putting [fitted|predicted]_draws.gam in gratia:

Pros:

• Does not duplicate functionality / just one function for users to learn
• Functions are maintained by someone with more knowledge of GAMs (i.e. you and not me)

Cons:

• If the interface changes in tidybayes, we would have to coordinate across packages. I suspect the main overhead here is argument names: see https://github.com/mjskay/tidybayes/issues/70 where even just supporting brms and rstanarm has required me to standardize argument conventions. Ideally I would like the interface for [fitted|predicted]_draws to stay as consistent as possible across model types.
• You may need to have gratia depend on tidybayes? I'm not sure how that works in general for generic functions across packages. tidybayes has a lot of dependencies so I'm not sure if you want to do that.

Pros / cons of putting [fitted|predicted]_draws.gam in tidybayes:

Pros:

• Annoying task of keeping arguments and formatting consistent across model types falls on me --- if things need to change across model types, that can be done in one package, simultaneously.
• gratia does not need to depend on `tidybayes

Cons:

• Functions are maintained by someone with less knowledge of GAMs (i.e. me and not you)
• If gratia also has functions that do the same thing, now there's two ways of doing it for users (which could be unnecessary duplication / a less consistent user experience).

It might help to get some thoughts from other folks who are more experienced at this kind of cross-package coordination. I recall @alexpghayes may have had thoughts about this?

[alexpghayes]

I strongly recommend putting mgcv specific functionality all together in the same place, and then trying to match APIs as much as possible to make cross-package coordination easier.

If you don't want to depend on tidybayes just to get those generics, I would make a PR to generics and then import generics in both gratia and tidybayes.

Also @gavinsimpson, I've been meaning to follow up with you about tidymodels/broom#239 for ages now. It seems like tidy(), glance() and augment() for GAMs (at least with mgcv) should live in gratia over broom.