Finalize what is and is not included as public user interface in the packages, and tailor documentation accordingly

[beykyle]

For the purposes of the alpha release, we will provide a complete api documentation in the user guide. However, before the beta release, a conversation needs to happen about how exactly a user should interact with the package, and the user guide api docs should be tailored to include that subset of functionality. It makes sense to leave this to the beta release as it is likely we shuffle some things between private and public by then.

The full api documentation can be preserved in the developer guide.

[jared321]

This should also include a review of the state of testing in terms of coverage by line and coverage by requirement. This could help make certain interface design decisions.

For instance if we keep the parse_* functions in the public interface and add a higher-level Results class to the public interface, would we need to have unit tests for both the parse_* functions and similar member functions in Results? If the parse_* functions are moved to the private interface is it acceptable to only test them implicitly through testing Results?

When this issue is closed, should we expect to have the test suite in a state that we consider to be reasonably complete?