frosting layer that creates point and quantiles for any trainer

[dsweber2]

There are a couple of ways of going about this:

1. When making the frosting, determine which layers to insert; this requires the user to hand the trainer used when defining the frosting part of the workflow
2. determine at runtime the type of .pred, and dispatch on that. to actually implement, this requires one of
   1. copy-pasta-ing large sections of the slather.layer_quantile_distn, slather.layer_point_from_distn, slather.layer_predictive_distn, and slather.layer_residual_quantiles (I think this is a bad idea)
   2. dispatching to the existing slather.layer functions (seems like it would be messy, and would involve faking having the correct objects in the workflow).
   3. refactoring the slather.layer* functions above so that the core doesn't depend on being in a workflow, and then reuse inside (this seems like probably the correct thing, but also fairly involved. Would definitely want to confirm if this is a good plan before potentially messing up the internals).

At the moment, this just does 1; from a user's perspective, the difference isn't that great, so for now I'm doing the easy to implement one, and will come back to a different one based on feedback.
The current function signature is

layer_point_and_distn <- function(frosting, trainer, ...,
                                  probs = c(0.05, 0.95),
                                  symmetrize = TRUE,
                                  by_key = character(0L),
                                  distn_name = ".pred_distn",
                                  point_name = NULL,
                                  distn_id = NULL,
                                  point_id = NULL,
                                  point_type = c("median", "mean"),
                                  truncate = c(-Inf, Inf),
                                  use_predictive_distribution = TRUE,
                                  dist_type = "gaussian")

The arguments are also... maybe a bit much, since they're the arguments of the 4 relevant functions jammed together. This does give the full range of flexibility of the original functions though, and I'm not sure there's a nicer way of guaranteeing that (suggestions welcome).

I'm a bit confused about the difference between probs and levels; it seems like they do the same thing, but have different default values? I put the two together to decrease the plethora of variables above.

[dajmcdon]

Meta comment: why add this functionality to this package? I can see how this might help in production, but does this simplify / enhance the experience for the average user? We should add to the agenda for the next tooling meeting.

On probs / levels, see #147

[dsweber2]

I would assume the average user isn't going to care that terribly much how their quantiles are produced, and whether they're currently working with quantile_reg or linear_reg. But it's on the pile of topics for the tooling meeting