Quick dirty html build

[ascholerChemeketa]

I rebased this code off of #2328 as the logic re: runestone-services overlaps and that other PR seems more fundamental.

This adds html.quick-dirty string param. It cuts out build steps when used on its own. When used with -r it prunes the source tree early in the assembly phase and really shines.

The results are not all that dirty... quick and dirty produces clean diffs.

Sample book                                           ~35 seconds
Sample book -r inactive-code                          ~20 seconds
Sample book -x html.quick-dirty yes                   ~23 seconds
Sample book -r inactive-code -x html.quick-dirty yes  ~1.6 seconds

[ascholerChemeketa]

@rbeezer @oscarlevin Our discussion in drop in mostly assumed quick and dirty would in fact be dirty. Since it is cleaner than expected, it might make sense to always enable it when -r is used. I'm not sure I see a use case for just -r without html.quick-dirty yes. Especially since -r is already marked experimental and possibly not reliable. But in the pretext script as swiss army knife philosophy it might make sense to keep them discrete.

For the CLI, the case seems stronger to make building a subset always use quick and dirty. Possibly with an opt-out switch and a message that subset building is not guaranteed to be artifact free.

[bnmnetp]

Kind of jumping in to the middle here, but I'm seeing a potential use case on Runestone.

An instructor types in a question in PreTeXt, we take the PreTeXt and add it to a mimimal book, where we then build the subset of that book containing this one exercise. Looks like it could be quite fast!

Then we extract the generated html to preview and save to the DB. This is essentially what we do today, but I think we could do it with the cli and not have to spin up another process.

[ascholerChemeketa]

Rebased and updated against master post @rbeezer update to Runestone logic.

Retested.

[ascholerChemeketa]

Force push after rebase on current master