centralize md instance as part of the normalized configuration

[Fil]

A bit of refactoring before addressing #92, and maybe reviving #702.

[mbostock]

It’d be helpful to have some more context in the PR description as to why we want to do this. It seems mostly internally-focused and the advantage of doing this isn’t clear to me.

Also, one particular risk I noticed is that the md argument is optional to parseMarkdown, meaning that it will fallback to a default instance if we forget to pass it in. This pattern can sometimes mask bugs because there are multiple call points to this function, and in particular we parse again during live update and that codepath is not well tested by unit tests.

And lastly there is #597 which may want to remove our dependency on markdown-it entirely… although I’m guessing we’ll instead want to do inline expressions as a preprocessing step and keep markdown-it.

Anyway I would like at least to understand the goal here so we can prioritize.

[Fil]

As I was working on #92 (now with PR #1037) I wanted to pass down an additional option to markdown ("cleanUrls"). I saw that we were creating a new instance of md for each page, with a root option that wasn't used at all, and a path option that was redundant (it could be read from the context). We were also calling markdownIt — the new option that adds custom plugins — once per page. All this seemed non-optimal on principle, and I didn't want to add another option on top without cleaning this up.

Also, as suggested by the link to #702, this could allow an implementation of md that makes use of a cache, to avoid parsing repeatedly the same files when we build.

The optional md is there for some of the unit tests, I can give them a custom md instead to avoid hiding a bug.

Creating a new instance of md is fast, so this did not translate into visible gains in execution time.