Use _quarto.modules registry instead of redundant module requires in filters

[cderv]

When packaging the Lua filter bundle, Pandoc's Lua interpreter enforces a 200 top-level-local-variable limit (MAXVARS) across all inlined filter files. main is already at that ceiling with zero headroom, which surfaced while evaluating room to bump the bundled Pandoc to 3.10.

modules/import_all.lua already centralizes most modules/* requires into a single _quarto.modules registry table, at no additional local-slot cost no matter how many modules get registered. But ~24 inlined filter files still redundantly re-required the same modules (constants, patterns, lightbox, scope, typst) as fresh top-level locals instead of referencing the existing registry - each costing one slot in the shared budget.

This replaces those redundant local X = require("modules/Y") aliases with direct _quarto.modules.Y access at every call site. Pure access-path change to an already-loaded singleton table - no logic or API change.

26 alias declarations removed across 24 files. Packaged bundle main.lua top-level local count drops from ~200 to 173.

Verified manually: packaged quarto check passes with no "too many local variables" error, packaged renders of lightbox (HTML) and typst (PDF) fixtures succeed, and smoke-all chunks covering the edited filters (2022, 2023/01) pass locally.

Follow up on #14664 where we hit the limit

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[cscheid]

This is a really great LLM task! Maybe it's worth taking a longer look at the Lua files and trying to move more of those files out.

Although, make sure to remember that these Lua changes are not truly tested in the test suite, and that we should probably do a bit of manual testing with the actual software bundle.