Review/Improve case-insensitive handling of custom function lists

[jrfnl]

Bug Description

A number of sniffs allow for custom function lists to be taken into account by the sniff(s).
Think, for example, the EscapeOutput sniff allows for custom printing functions and custom escaping functions to be added via a ruleset.

While function name comparisons around these lists are largely done case-insensitively, it looks like the user-provided custom function lists are not lowercased when they are merged with the base lists, meaning that currently sniffs may have false positives/false negatives due to a case-sensitive function name comparison being done against the custom functions.

I think we should review all places where custom function list properties are being merged with base lists and should make sure that the custom function list input is lowercased before any comparison is being done against the merged list (or maybe we should just lowercase the merged list to be on the safe side anyway).

A similar issue was fixed in #2572

Minimal Code Snippet

Example for the EscapeOutput sniff, though there are bound to be more sniffs affected:

// phpcs:set WordPress.Security.EscapeOutput customPrintingFunctions[] to_screen,my_Print
to_Screen( $var1, esc_attr( $var2 ) ); // Bad x 1, but would currently not be flagged
my_print( $var1, $var2 ); // Bad x 2, but would currently not be flagged.

// phpcs:set WordPress.Security.EscapeOutput customEscapingFunctions[] Esc_Form_Field
// phpcs:set WordPress.Security.EscapeOutput customAutoEscapedFunctions[] post_Info,Cpt_info

echo esc_form_field( $var ); // Ok, but would still be flagged.
echo Post_Info( $post_id, 'field' ); // Ok, but would still be flagged.
echo cpt_info( $post_type, 'query' ); // Ok, but would still be flagged.

Tested Against develop Branch?

• I have verified the issue still exists in the develop branch of WordPressCS.

[rodrigoprimo]

@jrfnl, while searching for something unrelated, I found #2508, which describes the same problem for EscapeOutput. Mentioning it here to link both issues. I'm not sure how you prefer to organize them, as this issue partially duplicates what is described in #2508, but has a larger scope.

[dingo-d]

Is this related to my closed PR: #2391? I so I can reopen it so somebody can pick that up.