Design overall checking function

[larryfenn]

In development we've created a few types of checks. Some make sense to run inside a pipe, but others operate as more of a tool for examining the contents of a data frame. For end-users, we need an overall interface that is easy to grasp.

The most straightforward path is to follow Michelle's structure and make functions for users the same way. For example, since ETL is all one section, we would pull out all the functions that were pipeline appropriate for ETL and call that check_etl(...), and all the functions that serve a more diagnostic purpose left to be invoked one at a time.

[larryfenn]

This is no longer really the way the library is intended to work. Instead, the API for users should be something like:

• Individual tests are all exposed in case someone wants to run a specific check.
• Group tests up in reasonable groups by their interface to make it easy for a user to run a single pass of a particular task -- for example, all import checks that take only as a requirement the data.frame & output either PASS or FAIL w/ row numbers of failing rows.