Accept `null` as a valid version argument for wp_enqueue_style()

Bug Description

When a script is enqueued through Google Fonts that loads multiple font families, the family parameter is used in the URL more than once. When wp_enqueue_style() adds a ver parameter to this URL, all but one of those family parameters is removed. This is a bug in PHP and/or WP core, see: https://core.trac.wordpress.org/ticket/49742

To work around this, null can be passed to wp_enqueue_style() as the version number. This results in no version string added to the URL.

When null is used as the version argument for wp_enqueue_style(), two PHPCS errors apply:

• WordPress.WP.EnqueuedResourceParameters.NoExplicitVersion is shown first, because it sees the argument as falsy.
• WordPress.WP.EnqueuedResourceParameters.MissingVersion is shown once that is ignored, because it sees null as the same as no argument being passed.

I would argue that in this case, the use of null is an explicit decision that should be treated the same as adding a valid version number. (This is mostly because it felt strange to have two different ignore statements for 4 characters of code)

Minimal Code Snippet

wp_enqueue_style( // phpcs:ignore WordPress.WP.EnqueuedResourceParameters.NoExplicitVersion
	'google-variable-fonts',
	'https://fonts.googleapis.com/css2?family=Roboto+Slab:wght@400..800&family=Work+Sans:wght@300..800&family=Work+Sans:ital,wght@1,300..800',
	array(),
	null // phpcs:ignore WordPress.WP.EnqueuedResourceParameters.MissingVersion
);

Environment

Tested Against develop branch?

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

Start by reading the WordPress.WP.EnqueuedResourceParameters.NoExplicitVersion and MissingVersion sniffs that report on wp_enqueue_style() arguments. Trace how a null version is classified, then verify that it is treated as an explicit version without either diagnostic applying; the issue should remain compatible with the stated PHP_CodeSniffer and WPCS versions.