Make dscr minimally ready for broader collaboration

[ramanshah]

• Strip the dscr API down to as few exported commands as possible, and rename them in snake_case (Naming conventions  #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 (Convert dsc to BatchExperiment to allow easy submission of jobs to cluster #23, Integration with batchJobs #46)
• Complete some vignette work to illustrate the tooling for fixing mistakes and working noninteractively (Big if-else datamaker in one_sample_location #35, vignette does not illustrate reset_dsc #47, vignette does not provide good overview of work flow #48)
• Flesh out the reset functionalities so that other phases of the computation can be reset (add reset scores, reset parser #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 (Clean build #38)
• Input parsers or any more depth/complexity to the workflow hierarchy (input parser #42)
• Smarter handling of the dependency graph (discussion in add reset scores, reset parser #43)
• Tooling for safe partial reruns of a project as the code itself changes (discussion in add reset scores, reset parser #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.