Allow filters to be excluded from the PHPFilterFunctions restricted list

[GaryJones]

Summary

The WordPressVIPMinimum.Security.PHPFilterFunctions sniff flags FILTER_DEFAULT and FILTER_UNSAFE_RAW because they perform no sanitisation. That was uncontroversial until PHP 8.1 deprecated FILTER_SANITIZE_STRING with no direct replacement. The pattern developers were pushed towards is to read the value with FILTER_UNSAFE_RAW (or no filter at all) and sanitise it themselves afterwards. The sniff then flags that deliberate, correct code, and there is no way to opt out short of a blanket ignore annotation, as raised in #753.

This adds an exclude_filters property so a ruleset can drop specific constants from the restricted list, for example to permit a knowing use of FILTER_UNSAFE_RAW:

<rule ref="WordPressVIPMinimum.Security.PHPFilterFunctions">
    <properties>
        <property name="exclude_filters" type="array">
            <element value="FILTER_UNSAFE_RAW"/>
        </property>
    </properties>
</rule>

The property defaults to an empty array, so nothing changes unless a ruleset opts in.

Design notes for reviewers

The issue asked for the $restricted_filters property to be made public. I have deliberately not done that. Exposing the default list hands ownership to the user: they would have to redeclare the whole list to remove one entry, and any constant VIPCS adds to the defaults later would be silently masked by their override.

Instead $restricted_filters stays private and the effective list is derived by subtracting the user's excludes, reusing the RulesetPropertyHelper::merge_custom_array() plus array_diff_key() idiom already used for the exclude property in RestrictedExtendClasses and AbstractVariableRestrictions. So VIPCS keeps ownership of the defaults and the user only expresses their delta. RulesetPropertyHelper is internal to WordPressCS, but VIPCS already relies on it in AbstractVariableRestrictionsSniff, so this introduces no new coupling. The subtraction is recalculated on each call rather than cached, matching that precedent, so an inline phpcs:set change is honoured mid-file.

One naming decision is open to bikeshedding: I went with exclude_filters (descriptive form of the existing exclude idiom). allowed_filters (positive framing) or a plain exclude (maximal consistency with the abstract sniffs) are equally reasonable — happy to rename before merge.

Fixes #753.

Test plan

Unit tests use the inline phpcs:set mechanism to prove that excluding FILTER_UNSAFE_RAW silences it while FILTER_DEFAULT remains flagged. I also verified the real ruleset-property path end to end: with the default config both filters warn, and with exclude_filters set only FILTER_DEFAULT warns.

• composer test -- --filter PHPFilterFunctions
• composer cs -- WordPressVIPMinimum/Sniffs/Security/PHPFilterFunctionsSniff.php