Add WIP example multiverse article and distill theme

[TwoTau]

🚧 WIP 🚧

Adds an example of the Frequentist Multiverse paper and Distill theme.

Also:

• Adds tangle-toggle and tangle-adjustable-option components based off the TangleKit.js library that the multiverse papers use
• Allows setting theme in the frontmatter of an article

Link: https://homes.cs.washington.edu/~vishald/lpub/multiverse/

TODO:

• [ ] Figure out how to render other components inside of attributes of other components: [:tangle-toggle:]{values=["untransformed\ data","log-transformed\ data\ [@Sauro2010]"] bind=log_transform} doesn't render the citation
• [ ] Finish working on Distill theme
  • [ ] Table of contents would be useful
• [ ] Preload images like the multiverse paper to avoid image flickering
  • The multiverse paper's preloading is a bit messy; they have a huge images.txt file listing every possible image URL and then request each of them. Is there a more programmatic way we can automatically preload images?
• [ ] Automatically convert jpg/png images to PDFs during compilation so that LaTeX can render images

[jheer]

Regarding this item: Figure out how to render other components inside of attributes of other components: [:tangle-toggle:]{values=["untransformed\ data","log-transformed\ data\ [@Sauro2010]"] bind=log_transform} doesn't render the citation

This raises an interesting issue for us. Currently our parser does not process markup within attributes. Currently the most common way we pass content through for parsing is to use a block-level component, for example something like this:

::: tangle-toggle {bind=log_transform}
- untransformed data
- log-transformed data [@Sauro2010]
:::

Then the interior content will run through standard parsing and it is the job of the tangle-toggle component to decide what to do with the generated content. However, not only must the component then translate its content to a parameter, the result is a block component instead of an inline component. I could imagine transformations that fix this, but at the cost of complexity and inconsistency.

Alternatively, inline components can accept content as well. For example:

[:tangle-toggle: Here is _parsed_ content]{bind=log_transform}

But here the internal content must only consist of inline elements and again the component must interpret/translate the content into a parameter. For reference, the span element parsing can be found at parse-pandoc-ast.js#L525.

Finally, there is the question if we should change the parser to parse attribute text and if so, when and how. In this case, we'd need to (1) parse the array content as JS/JSON, (2) run each element through the parser, (3) figure out how the component then handles the result (e.g., do we have to run AST fragments through the HTML code generator as well?).

There is enough uncertainty here that for now I'd argue for just omitting the citation, and let this PR move forward separately from these questions.