Randomized FITB components implemented

[dbrianwalton]

I took the work the @bjones1 did in the old RunestoneComponents repository for dynamic (randomized) FITB components and reimplemented the work under the new MonoRepo. Hopefully this makes a good starting point to pick up the next step in getting this implemented.

[dbrianwalton]

Answering some questions @rbeezer posted in the associated PreTeXt PR.

• As far as I can discern, the updated code looks for the existence of an additional field in the problem JSON structure (dyn_vars). If that is missing, the code uses the old tests. If it is present, then the additional structure for randomization and substitution takes place.
• One area I don't yet understand on Runestone is storage in the database (maybe localStorage only?). In .../interactives/fitb/js/fitb.js, setLocalStorage and restoreAnswers appear to store and then retrieve a second copy of the problemHTML (lines 411-416). I don't understand the rationale for this if the problem could be regenerated by the seed that was stored (and in fact is evaluated in restoreAnswers (line 369). Perhaps it is more related to formatting of feedback that was previously computed?
• Old problems would not have this html stored, but it looks like the code just skips this update if that element wasn't present. So I think this also should work fine for author-coded problems.

I did notice on my more careful review of how this interactive was implemented that a spurious change in versions for webpack was introduced due to my own misconceptions about npm and webpack. I've pushed a commit to resolve that so that versioning matches what was there before.