Make _config.yml have top-level keys that map onto extensions

[chrisjsewell]

With new versions of myst-parser and myst-nb, file-level configuration is now available under the myst/mystnb` "namespaces":

• https://myst-parser.readthedocs.io/en/latest/configuration.html#local-configuration
• https://myst-nb.readthedocs.io/en/latest/configuration.html#file-level-configuration

Both of which are auto-generated from a central "source of truth"

This may also be the case with the sphinx-book-theme: executablebooks/sphinx-book-theme#557

It would be desirable for the _config.yml to have the same structure, e.g.

general:
  author: Bob Geldof
myst:
  enable_extensions: [deflist]
mystnb:
  execution_mode: auto
theme_html:
  collapse_sidebar: true
other:
  suppress_warnings: ["myst.strikethrough"]

To address issues like #1673, it might also be desirable to first run the YAML through jinja, with filters added to handle general use cases, e.g. for environmental variables:

mystnb:
  execution_show_tb: {{ true if env('READTHEDOCS') else false }}

cc @choldgraf @mmcky

[choldgraf]

I think this is an important topic to get correct in order to avoid us having a lot of configuration confusion in the future. I agree with @chrisjsewell's assessment here - it would simplify our configuration considerably if we could have a reliable parent_key -> configuration for parent mapping pattern. This could also have the benefit of minimizing documentation and upgrade toil as these configurations change over time.

For example, many Sphinx configurations begin with {prefix}_option_name (e.g. nb_execution_mode). It would simplify our configuration considerably if we could make assumptions like:

mystnb:
  execution_mode:

maps directly on to nb_execution_mode. Then we could reduce the user friction associated with seeing two different configurations for the same tool (one in Sphinx and one in Jupyter Book).

Then we could also start to remove unnecessarily idiosynchratic configuration differences that we need to hack around with stuff like:

https://github.com/executablebooks/jupyter-book/blob/a72e43ae5755515208a028f69b3d17c4d0c4a062/jupyter_book/config.py#L333-L342

I can't tell if this is what @chrisjsewell is suggesting or not so wanted to throw it out there 😅

[chrisjsewell]

many Sphinx configurations begin with {prefix}_option_name (e.g. nb_execution_mode). It would simplify our configuration considerably if we could make assumptions

Oh yeh, this is literally how the config is generated, for myst-parser and myst-nb, you just iterate over the config dataclasses and add the prefix:

• https://github.com/executablebooks/MyST-Parser/blob/602470ebdaf81fbea999fcc0f0cf1b8e7784ec15/myst_parser/sphinx_ext/main.py#L50
• https://github.com/executablebooks/MyST-NB/blob/2428268b0e436df4ad2281c24408326bf38117de/myst_nb/sphinx_ext.py#L128

[mmcky]

I really like the namespaces idea here.

This will also really help align options with their software "layer of responsibility".