Update QMCPACK documentation style

[brockdyer03]

Proposed changes

As noted in #5044, there is a desire for better documentation for QMCPACK.

This branch is quite old, and has not been touched in a while, but I think for the most part the changes I've made in it still hold up. I need to do some more cleaning, but I very much need some external input from QMCPACK maintainers on what should go where and how things should be structured.

What type(s) of changes does this code introduce?

• Documentation or build script changes

Does this introduce a breaking change?

• No

What systems has this change been tested on?

Laptop, Fedora Linux 44 (KDE Plasma Desktop Edition)
AMD Ryzen 7 PRO 7840U (8 cores, 16 logical processors)

Python        3.14.6
uv            0.12.5
cif2cell      2.1.0
coverage      7.15.4
h5py          3.16.0
matplotlib    3.11.1
numpy         2.5.2
pycifrw       4.4.6
pydot         4.0.1
pytest        9.1.1
pytest-cov    7.1.0
pytest-order  1.5.0
scipy         1.18.0
seekpath      2.2.1
spglib        2.7.0
sphinx        9.1.0

Checklist

• • I have read the pull request guidance and develop docs
• • This PR is up to date with the current state of 'develop'
• • Code added or changed in the PR has been clang-formatted
• • This PR adds tests to cover any new code, or to catch a bug that is being fixed
• • Documentation has been added (if appropriate)

[prckent]

On review, I think it would be better to first respect the existing document structure. i.e. All ~20 "sections". Once the new style is enabled we could revise from there. In nearly all cases we will want to show the first & second level titles. e.g. Introduction->Quickstart should be visible on the first page, unlike this version.

[brockdyer03]

On review, I think it would be better to first respect the existing document structure. i.e. All ~20 "sections". Once the new style is enabled we could revise from there.

The issue with leaving it flat is that the new theme will try to put all of the items on the top bar and since it can't fit it'll make a dropdown that hides them.

I can increase the depth of the first page so that more is shown, and I can also do what I did for the Nexus docs and made some friendly buttons so that things are a bit easier to find, but I definitely don't think we should stick to the flat layout.