Docs: Expand QUnit.config.testFilter docs

[gbudjeakp]

This PR implements QUnit.config.testFilter, a new configuration option that allows programmatic filtering of tests at runtime through a callback function.

Context:
Currently, QUnit provides filtering through CLI parameters (--filter, --module, etc.) and test-level methods test.only(), test.skip(), but there's no way to implement dynamic, programmatic filtering based on runtime conditions without modifying test code.

This feature enables several important use cases:

• Quarantining flaky tests in CI without modifying test code
• Parallel test execution by distributing tests across workers via hash-based sharding
• Runtime capability detection to skip tests for unavailable browser features (WebGL, IndexedDB, etc.)
• Dynamic test selection based on external data sources (APIs, configuration files)

Fixes #1814.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: gbudjeakp / name: Akpevwen Sebastian Gbudje (b795e77)

[Krinkle]

In terms of code and execution order it is:

• Test methods test.only narrows irrevocably, removal is final.
• Test methods test.if and test.skip disable irrevocably but don't remove (later layers see it).
• config.moduleId, narrows irrevocably.
• config.testId, narrows, and inclusion is immediate and final. Later layers don't even run.
• config.module, narrows irrevocably.
• config.filter, narrows irrevocably.
• config.testFilter, narrows further, seeing ony what hasn't been filtered out before, except for if/skip, which do get seen here. A testFilter cannot re-enable a skipped tesrt, but it can decide whether to filter. The effect is whether or not the skipped test is reported. This makes sense when distributing tests, because a skipped test should be allocated and reported on, once, just like any other test.

The order documented here is different, but maybe the order doesn't matter? Is there a specific meaning conveyed with this order? Would it mean something different to you as a user, if the order was described as 1) CLI, 2) Programmatic, 3) Test-level? This isn't a suggestion, I'm only asking as example, to help understand intent.

[gbudjeakp]

I structured the docs conceptually (test-level → programmatic → CLI) thinking it would be easier to understand ( That's the way I was thinking about it at the time in my head with the scenarios I was thinking off). The order doesn't matter here but from a users perspective(especially for debugging), that might be a bit confusing. I should update the doc to match.

The correct order is:

1. Test-level filters run first: test.only(), test.skip(), test.if()
2. CLI/URL filters run last: --filter, --module, --moduleId, --testId
3. Programmatic filter runs last: QUnit.config.testFilter

[Krinkle]

I'm landing the 2.x backport first, so the docs review is non-blocking. No rush :)

[Krinkle]

I've landed a minimal version in 1ee3e2c for the 2.25.0, docs site, and release notes. I've then rebased this PR to iterate on the docs further.