Make dscr minimally ready for broader collaboration

[ramanshah]

• [x] Strip the dscr API down to as few exported commands as possible, and rename them in snake_case (#44). This is a serious breaking change, and I'd have to assist students in getting all their dscs back on the rails subsequently.
• [ ] Replace the guts of the execution engine with BatchJobs registries for parallel execution (#23, #46)
• [ ] Complete some vignette work to illustrate the tooling for fixing mistakes and working noninteractively (#35, #47, #48)
• [ ] Flesh out the reset functionalities so that other phases of the computation can be reset (#43)
• [ ] Assist in the process of packaging only the code and .RDS scores (as opposed to raw data or the other cached results of computation) as a Git repo such that the repo size is GitHub-friendly (this is a new one)

At that point, I think that dscr repositories (versioned under Git and hosted by GitHub) should be effective enough to facilitate new methodological collaborations, where new scenarios or methods could be shared via GitHub pull requests. Rerunning other people's computation (to get the non-score stuff) could be done on an as-needed basis, but the idea is that such "auditing" tasks would be rarer than adding code and scores to the repo.

This specifically punts on some of the other directions in the interest of time:

• CRAN-ready or otherwise cleanly engineered build (#38)
• Input parsers or any more depth/complexity to the workflow hierarchy (#42)
• Smarter handling of the dependency graph (discussion in #43)
• Tooling for safe partial reruns of a project as the code itself changes (discussion in #43)

@stephens999 This is fully open to debate.

[stephens999]

my only quick comment regarding renaming in snake_case is that I might prefer to (at least initially) keep the lower-camel-case functions around, and mark them as deprecated. (ie have them emit a warning, but still work) as an intermediate step to avoid breaking existing dscs.

[ramanshah]

Sounds good.