Don't show h1s in module page table of contents

[Eric-Arellano]

Closes #932.

We decided:

1. We are going to keep showing h1s for class and function pages. It's useful because they have non-trivial code at the top level, like their docstring and constructor. It's nice to have the quick way to access the value.
2. For now at least, we won't show h4s in the module pages. There are 8 module pages in the current API docs that use h4s. I think showing h4s improved ~3 of them, and made ~5 worse. So, for now, let's not include them. This can be revisited, especially after Initial audit of header hierarchy for all module API pages #942.

This regens all APIs but reverts dev docs, which have unrelated changes and will be regenerated in a dedicated PR.

[Eric-Arellano]

Any opinion on whether we should simply not set the line in_page_toc_min_heading_level for modules since 2 is already the default? It makes zero difference for the docs app / for users. I figured always setting in_page_toc_min_heading_level was simpler code, and it also maybe makes more explicit to devs the difference between class pages & module pages.

[arnaucasau]

Thanks!