Apply Markdown and HTML styling

[lognaturel]

Collect's implementation: https://github.com/getodk/collect/blob/e49eae16657d6677abde44e4475c1f08d3ccf9ae/collect_app/src/main/java/org/odk/collect/android/utilities/HtmlUtils.java#L23

• It includes some subtleties such as Only treat _ as markdown if separated by white space enketo/enketo#24

Documentation: https://docs.getodk.org/form-styling/#markdown

Enketo allows disabling style: https://github.com/enketo/enketo/blob/37a7af1886743c7e20ddcb9f3b0f8708d184cd88/packages/enketo-transformer/README.md?plain=1#L85

• @eyelidlessness: "I think it’s something we might want, eg maybe for like summary views. Either way I think if we’re gonna parse it, that would happen in the engine, and then we tailor the representation to what clients need and what makes the most sense for all of the common concerns around markdown. Structured data feels much safer to me than serializing it in the engine, both in terms of security and client flexibility"

Possible subtleties around using dynamic values in links: enketo/enketo#804

Consider using https://github.com/remarkjs/remark

[eyelidlessness]

Possibly of interest, re: approaches to achieving a subset of Markdown: remarkjs/remark#552

Depending on what we want to do with Markdown syntax we don’t support, it may be as simple as disallowing certain AST node types (as in, parse known-but-unsupported syntax and strip Markdown semantics from it), which Remark and/or related tools support directly. Or it might be more complex if we want to prevent use of certain Markdown features, preserving the actual syntax characters for those features as if they’re plain text. (The latter is likely more consistent with the existing reference implementation, but we might find we want to tweak the particulars of that depending on how we address it in the spec.)