Implement score class + attribute for the output of score()

[nikosbosse]

Update

We decided that score() outputs an object of class score with a single attribute scoring_rules

---

Old description

Questions:

• what should the class of the output of score() and / or summarise_scores() be?
• should the output have any additional attributes?

Current behaviour on the development branch: The output of score() retains its class, i.e. is still an object of class forecast_binary.

One disadvantage of this is that if you try to run score() again on that output, then unexpected things happen (i.e. you get a complaint that predicted and observed are missing). @seabbs therefore suggested to have a new class for the output of score().

Desirable features of a solution:

• we might want to know the type of the forecast before scoring. I don't have anything specific in mind, just a vague feeling that that could be useful. Maybe something like special plots, depending on the type of the forecast?
• we want to be able to run get_forecast_unit() on the output. This is necessary e.g. for pairwise comparisons and helpful for plotting.
• An equivalent version of framing the last point: we want to know the names of the scoring rules used for scoring (i.e. the column names of everything that is a score). --> everything that is not a score is part of the forecast unit

Updated my thinking a bit about the following:

• We probably don't need to keep track of
  • the level of summary in summarise_scores(), i.e. by
  • the level of summary in add_pairwise_comparison()
    The main use case I see for this is if you want to share the by argument across different function calls (i.e. you set it once, and another function respects it). But that seems brittle and dangerous. If we're able to track the names of the scoring rules used for scoring, then we'd automatically have the summary level of summarise_scores() (i.e. all columns that are not a score).

I would propose to give the output of score() a new class, e.g. score. Functions like add_pairwise_comparison() or summarise_scores() would not get their own output class. I don't think their behaviour is so different (e.g. for plotting) that we would really need a new class.
I'm not even sure I would restrict them to accepting an object of class score as input (but have to rethink a bit).

I currently don't see a good way to get around setting attributes to keep track of the names of the scoring rules used within score(). What do you think?

[nikosbosse]

Decision:

• score() outputs an object of class score with a single attribute scoring_rules

[nikosbosse]

I just realised that in #588 and #590, we named a function get_score_names().

There is probably an argument to be had about whether score_names is the best name. According to #520, "scores are computed by scoring rules". So the score is the output of a scoring rule. In some sense, the function gives you the names of the columns that hold the scores. Is that the name of the score? The name of the scoring rule?

This is a bit at odds with our previous decision to name the attribute scoring_rules. Are we happy with score_names instead of scoring_rules? @sbfnk @seabbs

Round and round and round it goes...