New metric vec template

[EmilHvitfeldt]

This PR adds a refactoring of metric_vec_template() into numeric_metric_vec_template(), class_metric_vec_template() and prob_metric_vec_template().

At the same time it also refactors validate_truth_estimate_checks() into validate_factor_truth_factor_estimate(), validate_factor_truth_metrix_estimate(), validate_numeric_truth_numeric_estimate(), and validate_binary_estimator() which are being called inside *_vec() functions.

Old functions are soft deprecated

[EmilHvitfeldt]

@DavisVaughan You are NOT allowed to look at this yet! I need to sleep and do another pass

[DavisVaughan]

I think this is definitely moving in the right direction. I think this idea of moving validation into the metric functions themselves is really smart, and very powerful!

I provided some fairly high level feedback. My main thought (which I have put in detail below, mainly here #337 (comment)) is that I'm wondering if we can make this even simpler, more flexible, and more robust by breaking down the jobs performed by the 3 new vec-template functions into multiple helper functions that we'd force the metric functions to call themselves.

I think I was a bit obsessed with trying to shoehorn everything into 1 metric_vec_template() function, but that has proven to be pretty strict and has kept some people from being able to write their extension functions.

Instead, exporting a number of optional check/validate/na_rm functions that authors could use in their own metrics as needed feels much less restrictive.

As I mention below, it also has the massive benefit of not needing to write your *_impl() function inside the *_vec() function (because we needed to use R's scoping rules weirdly), which I think makes this heavily worth considering

We can schedule some time to talk ASAP if you want to discuss this further

[DavisVaughan]

A number of comments about naming, and a request to open a few issues related to supporting class-pred in a better way and some issues with the curve functions, but overall seems like a really nice simplification, so I'm going to approve alongside this feedback

After addressing my comments, I would encourage you to do one big self review for grammar and documentation consistency, as this touches a lot of files and it is easy to get things out of sync

[github-actions]

This pull request has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue.