Enable integration of locally-defined checks

[mpadge]

Along the lines of riskmetric which just greps for specific function prefixes in the namespace.

[mpadge]

@dgkf This issue is an important step in bringing our pgkcheck system in line with riskmetric - I'm just using different prefixes, which I think is initially a good idea here (pgkchk_ here for your assess_ functions there). One important question: What is your main motivation for exporting all of your assess_ functions? Is it primarily to be able to export the documentation, so that users can easily see what each test does? Other than that, I see no advantage here of exporting them, and am currently pondering options for other ways to document them, while keeping a minimal namespace for the package (i.e., not exporting). Your insights and experiences from riskmetric would be really helpful here, please 😄

[mpadge]

@dgkf I guess you probably checked all this out at some stage too, but the structure of goodpractice provides a really interesting comparison. All test functions are just appended to a global list of CHECKS, which makes the code very clean and simple - more so, i'd say, than either pkgcheck or riskmetric. One big disadvantage is that checks have internal "description" entries -- like this covr example, or the first entries of all of the rcmdcheck checks -- but these are not at all accessible to users. Nevertheless, I just submitted a PR which would enable direct access to these "description" entries. That would in turn make that whole interface extremely attractive, mostly due to it being so utterly simple. New tests are also easier to add than is currently so in either pgkcheck or riskmetric - the whole procedure only needs one simple example to demonstrate.

The biggest downside I can see is that these new functions are not "first class" functions like the hard-coded internal ones, and can only be explicitly specified as extra_ parameters. Both of our packages (need an ability to) treat additional functions as proper "first class" functions, so can't (easily) follow this method.

More importantly, I want to ensure our packages only become more compatible over time, and not less, so don't want to make any design decisions at this point that are likely to reduce compatibility. Happy to discuss here, or we can wait only 2 days now until riskmetric "sprint" meeting. Maybe one to add to the agenda?