Add a check to recommend that the `%i` placeholders are used for identifier names instead of `$wpdb->tablename` or `%1$s`-like placeholders.

[craigfrancis]

Following up on PR #2072, and suggested by Juliette.

• This would need the same research as mentioned [in #2078].
• This check would need to use the MinimumWPVersionTrait to determine whether the recommendation should be shown or not, based on the minimum WP version a plugin/theme supports.

When it comes to %1$s-like placeholders, I'm very much in favour of this (it's why $wpdb->allow_unsafe_unquoted_parameters exists, and my plan over the next ~10 years is to eventually remove that risky feature, where %1$s-like placeholders are not quoted, because developers must remember to correctly add quotes themselves).

With $wpdb->tablename, I have created WordPress Ticket #56091 (specifically PR #3016), so WordPress could use %i for some table names. But my concern while making this PR was that it made queries a bit harder to read (it's not immediately obvious which table is being used). Also, I cannot imagine there are many developers who need their $table_prefix to contain characters other than [a-zA-Z0-9_]... that said, while I am aiming for wpdb::prepare() to require a literal-string for its first argument (i.e. a developer defined string), maybe that will be too hard for WPDB to check (being able to trace the variable back to all of its sources)?

[jrfnl]

WPCS can definitely not trace a variable back to its source as sniffs are mostly limited to one file only.

In most cases, it can check that the first param passed to wpdb::prepare() is a literal string though as in most cases, the query is passed directly in the function call or defined within the same (function) scope as the call to wpdb::prepare(), in which we could find it with a little token walking within the function scope.

[kkmuffme]

to be limited for minimum_supported_wp_version of 6.1 or higher