[INFRA] Enable version panel for quickly finding previous versions

[effigies]

Just a note that I'm playing with trying to get RTD to play nicely.

In our builds, it acts as if there's no configuration file (example):

Configure your documentation builds! Adding a .readthedocs.yml file to your project is the recommended way to configure your documentation builds. You can declare dependencies, set up submodules, and many other great features.

First thing I'm trying is to fix our configuration, and will host the results at https://bids-specification.readthedocs.io/en/rtdtest/ when I can get it to build.

Replaces #231.
closes #228

[effigies]

Some notes so I can close a ton of tabs:

• I've opened an issue (ReadTheDocs footer not being inserted readthedocs/readthedocs.org#5702) at RTD to check whether it's a bug on their end.
• ReadTheDocs seems to inject this file into most Sphinx-based projects. Possibly the issue is that it's not done by default on mkdocs.
• mkdocs has two built-in themes (https://github.com/mkdocs/mkdocs/tree/master/mkdocs/themes) and both seem to allow for the panel: stable (RTD theme), latest (mkdocs theme)
• The RTD theme for mkdocs seems to have explicit mention of versions, while the mkdocs theme does not.
• I've forked mkdocs-material (https://github.com/effigies/mkdocs-material/tree/enh/rtd_versions) to play around with adjusting the theme.

[effigies]

I found a project using mkdocs-material and that has the panel: https://mapstore.readthedocs.io/

[effigies]

Found via geosolutions-it/MapStore2#3570, we need to add JQuery. We now get

I'm going to squash this and merge into master.

[effigies]

Apparently I can't push fixes to master. Here's to more changelog clutter.

[sappelhoff]

great effort, thanks @effigies.

Regarding pushing to master: Is your idea that all INFRA changes should be pushed directly to master instead of taking our usual road of going via a PR (see rule 1. in decision-making)?

I don't see an issue with having INFRA PRs in our changelog, but would be happy to discuss it.

[effigies]

I think there should be two changelogs: the repository changelog and the specification changelog. When somebody's reading the spec, what they care about is what new features are there in the specification, and absolutely not what changes were made to the build system.

IMO, the specification changelog should ONLY include [FIX] and [ENH] changes, and should strip out the tags. I also think we should be able to go in and retroactively fix the changelog to be more human friendly without our changes getting destroyed every time a PR gets merged.

[sappelhoff]

+1, perhaps you can open an issue on this, because this PR will be merged soon and is a suboptimal place for discussion. Related: #164