Use the maxdepth option of the toctree directive to count the visible TOC items

[Amoifr]

Fixes #106, which tracked the FIXME left behind in #102:

// FIXME: this hardcoded '2' value should instead be obtained
// automatically using the 'maxdepth' option of 'toctree' directive.
$maxDepth = 2;

Good news: everything needed was already there. TocNode::getDepth() reads the directive's maxdepth option (falling back to 2), and TocNodeRenderer already passes tocNode to toc.html.twig — it just wasn't being used. So toc_options() now takes the depth as an argument:

{% set toc_options = toc_options(tocItems, tocNode.depth) %}

What was actually broken: with :maxdepth: 3 or more, the deeper items are rendered but were not counted as visible, so numVisibleItems was too low and the TOC got the wrong toc-size-* class — i.e. the wrong number of columns. That is exactly the symptom described in #102. A toctree with :maxdepth: 1 or 2 is unaffected, since the renderer never builds items below the depth anyway.

The parameter defaults to 2, so JsonGenerator — whose TOC is crawled from h2/h3 and therefore only ever has levels 1 and 2 — keeps behaving exactly as before.

Tests:

• a unit test on TocExtension pinning the count per depth (2 items on level 1, 4 on level 2, 8 on level 3 → 2 / 6 / 14 visible for maxdepth 1 / 2 / 3), plus the default;
• an integration fixture (toctree-maxdepth) with a :maxdepth: 3 toctree, sized so the bug is visible: 6 counted items before (toc-size-md), 14 after (toc-size-lg).

I checked the fixture actually fails without the fix — it reports toc-size-lg expected, toc-size-md given. Full suite green: 79 tests, 176 assertions (74 before).

Thanks for the tool — the docs wouldn't build without it. 🙂