Add Myst (new tech stack) workflow

[rossbar]

Simplest possible setup (with minimal instructions) for getting up and running with myst.

[rossbar]

One (of the many) goals of this project I think should be to serve as a "transition guide" from the existing myst-nb/sphinx stack to the mystmd stack. Here are some quick takeaways from comparing workflows:

Massive improvement (IMO)

• The decoupling of site layout from source layout is a huge improvement over the sphinx workflow. The ability to explicitly specify site layout in the myst.yml config file is a really nice feature, and eliminates one of the most common pain points with trying to get toctree(s) to give you the site layout you want. In my experience at least, this is an excellent new feature.
  • In principle it's also possible to envision having multiple possible layouts for a site. E.g. @danielballan expressed the desire for using the same source material to lead workshops for two different audiences; say one hardware-focused and one data-analysis focused. Since the config file is the source of truth for site layout, all that should be required is modifying/maintaining multiple site layout configs without ever having to touch the source material.

Needs

• A way to preview the site in CI - with the sphinx-based toolchain, we rely entirely on the fact that the site produced by sphinx is a pure static site that doesn't require any special hosting/web assets. This enables the pattern where we can push the build products (_build/html) uncompressed up to a bucket, then simply open a link to that URL in the browser to get the site preview. The discussion along these lines is captured in Add a myst preview subcommand jupyter-book/mystmd#2017.
• A few more hooks into the notebook execution - specifically, a way to escalate notebook execution errors to myst build errors. To be clear, the story isn't that great on the sphinx-side either: we currently rely on -WT --keep-going to get the behavior we most want (escalate warnings to exceptions, give full tracebacks, and continue executing the other notebooks) but this isn't perfect because the -W encompasses all sphinx warnings. We'd definitely want to have a way to continue treating myst build warnings/errors separate from notebook execution warnings/errors. See also Improve the execution experience in MyST jupyter-book/mystmd#2019