#1248 allowed deferring checking if a filter exists until runtime when writing the filter within in an if block. To make it easy to take advantage of such optionally available filters, this PR adds an is filter test.

This required allowing tests to be decorated with @environmentfilter. It's not clear why this wasn't allowed before. The docs mentioned it wasn't possible, but didn't give a justification. Perhaps the idea was that tests should be as simple as possible; if so that's up to the discretion of a project now.

Tests are essentially the same as filters now. The difference is only the syntax used to call them and the namespace they're registered in. Most of the code in nodes, compiler, and environment is common between the two, so it was refactored to extract it. Tests won't be constant folded in volatile contexts. The compile supports async tests, but I'm not declaring that a public API yet, as there's not really any way to write them or apparent need for them yet. Like filters, undefined test names are checked at runtime in if blocks.

Tests can be decorated with environmentfunction, evalcontextfunction, and contextfunction. Filters use {type}filter instead but do exactly the same thing internally, which led me to open #1381 to pick one set of names.

• fixes optionally use a filter based on its existence #842
• continues allow optional use of a filter based on its existence #1248

Checklist:

• Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
• Add or update relevant docs, in the docs folder and in code.
• Add an entry in CHANGES.rst summarizing the change and linking to the issue.
• Add .. versionchanged:: entries in any relevant code docs.
• Run pre-commit hooks and fix any issues.
• Run pytest and tox, no tests failed.