Refactor code so that checks have a defined structure, have an obvious place where they go, etc

[thisisnic]

A check is something that has:

• config in form of:
  • a threshold for what score results in a warning
  • a threshold for what score results in an error
  • an on/off toggle (active)
• a function to run to generate a score (scorer function)
• a function to run to display results (display function)
• a function to run to "mark" the results as a pass/warn/fail (grader function)

Would it make sense to have a "check" as an R6 class object which can be created via a helper function? Therefore, we can take advantage of OOP principles like subclassing etc, no passing big long lists around. Or, perhaps, like could be kept simple via a function, e.g. create_check(name, scorer, grader, display)

A checklist is something that:

• stores results of all checks
• orders/groups the checks
• runs the display functions
• sets up not-user-supplied checks

testthat uses reporters to collect test results together - this concept could be relevant here?

checks and checklists?