Score model out improvements

[nikosbosse]

(builds on #52)

This PR simplifies score_model_out, mostly by offloading a bunch of the heavy work to scoringutils. In particular it

• simplifies the documentation to mostly rely on the function explanations in scoringutils. Mostly a matter of taste - my impression is it make easier to maintain the docs in the future
• moves most of the logic for obtaining default metrics from hubEvals to scoringutils.
• amends the interval_coverage_XY a bit to allow for all numbers in (0, 100).
• restricts the metrics for mean and median forecasts to the ones suggested by Gneiting. Personally I think it makes sense to simply not return something we know is flawed.

Moving the logic to scoringutils makes the code easier and more concise. Errors are handled by scoringutils which comes with both upsides and downsides. The upside is it's all cleanly handled and we don't need to worry about it.

The major downside is that error messages are slightly less "nice". E.g. when you pass something like metrics = list("a", "b") to score_model_out, then you'll get an error message Assertion on 'c(select, exclude)' failed: Must be of type 'character' (or 'NULL'), not 'list'. If we don't like the current error messages I suggest we catch the errors and replace them with new messages. But I think it's still cleaner to have the logic be handled by scoringutils instead of re-implementing it here.

[github-actions]

🚀 Deployed on https://66e9da908633e26d033c3acf--hubevals-pr-previews.netlify.app

[nikosbosse]

Technically it's an object of class scores which is itself a data.table but probably easiest not to confuse users with scoringutils stuff

[zkamvar]

This is a much better descriptor. Thank you for catching it, especially since data.table can catch people off-guard since it doesn't behave like other R objects (i.e. modifying a data table will modify the object in-place as opposed to making a copy).

[zkamvar]

I think this looks good. I am all in favor of shunting the majority of the work and documentation to scoringutils.

I think we can live with the errors. Replacing them reliably in the future is so not fun. If anything, we might be able to catch the error and prepend it with "oh hey, something in scoringutils went wrong and here's the error message:"

[zkamvar]

This is a much better descriptor. Thank you for catching it, especially since data.table can catch people off-guard since it doesn't behave like other R objects (i.e. modifying a data table will modify the object in-place as opposed to making a copy).

[elray1]

These changes look good to me too, thanks for putting them together! I agree that better error messages would be nice, but I think the errors that people are most likely to encounter in practice are clear.