need to use read-only git url

Update Develop from main WPS Fork

The `$data` parameter of the `$phpcsFile->add[Fixable]Error|Warning()` methods is expected to be an array, not a string.

Without this fix, PHP 8 will throw and (uncaught) `TypeError: vsprintf(): Argument #2 ($args) must be of type array, string given`.

1. Adjusted the way the correct parameter is retrieved to use the new PHPCSUtils 1.0.0-alpha4 `PassedParameters::getParameterFromStack()` method.
2. Verified the parameter name used is in line with the name as per the WP 6.1 release.
    WP has been renaming parameters and is probably not done yet, but it doesn't look like those changes (so far) made it into changelog entries.... _sigh_.
    It also looks like in the past, deprecated parameters were being renamed to `$deprecated` on deprecation. This practice should be strongly discouraged in the context of named parameters, but that's a different discussion and outside of the scope of this commit.
    For the purposes of this exercise, I've taken the _current_ parameter name as the "truth" as support for named parameters hasn't officially been announced yet, so any renames _after_ this moment are the only ones relevant.
3. Adjusted the error message/data determination to take named parameters into account.

Name verification notes:
* Removed the `comments_link()` function.
    Per [the changelog](https://developer.wordpress.org/reference/functions/comments_number/#changelog), the previously deprecated fourth parameter is now being used for something else since WP 5.4.0....
    Far from best practice, but it is what it is, so I've removed the listing for that function.

What has **not** been done: a scan of the WP Core codebase to find newly deprecated parameters.

Includes additional unit tests and updating one existing test to ensure the code logic is properly covered.

Note: I thought of updating the error message to no longer refer to the position of the parameter, but to use the parameter name instead (with a "Found: %s" for displaying value), as in:
```bash
# Current:
The parameter "$variable" at position #2 of wp_new_user_notification() has been deprecated since WordPress version 4.3.1. Instead do not pass the parameter.

# Variation:
The $deprecated parameter of the wp_new_user_notification() function has been deprecated since WordPress version 4.3.1. Instead do not pass the parameter. Found: $variable
```
... but as WP renamed all deprecated parameters to `$deprecated`, this wouldn't necessarily be more descriptive than it is now.

Along the same lines, I considered updating the error code to refer to the param name instead of the position, but aside from it not making things more descriptive as things are, that would also constitute a BC-break which I don't think is warranted.

Opinions appreciated.

1. Adjusted the way the correct parameter is retrieved to use the new PHPCSUtils 1.0.0-alpha4 `PassedParameters::getParameterFromStack()` method.
2. Verified the parameter name used is in line with the name as per the WP 6.1 release.
    WP has been renaming parameters and is probably not done yet, but it doesn't look like those changes (so far) made it into changelog entries.... _sigh_.
    It also looks like in the past, deprecated parameters were being renamed to `$deprecated` on deprecation. This practice should be strongly discouraged in the context of named parameters, but that's a different discussion and outside of the scope of this commit.
    For the purposes of this exercise, I've taken the _current_ parameter name as the "truth" as support for named parameters hasn't officially been announced yet, so any renames _after_ this moment are the only ones relevant.
3. Adjusted the error message/data determination to take named parameters into account.

Name verification notes:
* Removed the `comments_link()` function.
    Per [the changelog](https://developer.wordpress.org/reference/functions/comments_number/#changelog), the previously deprecated fourth parameter is now being used for something else since WP 5.4.0....
    Far from best practice, but it is what it is, so I've removed the listing for that function.

What has **not** been done: a scan of the WP Core codebase to find newly deprecated parameters.

Includes additional unit tests and updating one existing test to ensure the code logic is properly covered.

Note: I thought of updating the error message to no longer refer to the position of the parameter, but to use the parameter name instead (with a "Found: %s" for displaying value), as in:
```bash
# Current:
The parameter "$variable" at position #2 of wp_new_user_notification() has been deprecated since WordPress version 4.3.1. Instead do not pass the parameter.

# Variation:
The $deprecated parameter of the wp_new_user_notification() function has been deprecated since WordPress version 4.3.1. Instead do not pass the parameter. Found: $variable
```
... but as WP renamed all deprecated parameters to `$deprecated`, this wouldn't necessarily be more descriptive than it is now.

Along the same lines, I considered updating the error code to refer to the param name instead of the position, but aside from it not making things more descriptive as things are, that would also constitute a BC-break which I don't think is warranted.

Opinions appreciated.

This commit fixes the test failure seen in PR 2499.

The test failure was surfaced due to a new exception in PHPCS (see: PHPCSStandards/PHP_CodeSniffer 524), which will be included in PHPCS 3.11.0.

The test failure highlighted that the above mentioned PHPCS PR needs a follow-up with some extra defensive coding, however, that defensive coding is needed in a part in PHPCS which does the error handling for PHP notices being encountered, i.e. the throwing of `Internal.Exception` errors.

This implied there was also an underlying issue in WPCS causing the `Internal.Exception`, which apparently was only triggered when the fixer was being run.

> Note: the fact that `Internal.Exception`s during a PHPCBF run are being suppressed is a known issue, but fixing that is not that easy, so that definitely won't happen before PHPCS 4.0 (and may not even make it into 4.0). See: squizlabs/PHP_CodeSniffer 2871

Either way, I've looked into the `Internal.Exception` now.
The error was as follows:
```
An error occurred during processing; checking has been aborted. The error message was: PHPCSUtils\Utils\GetTokensAsString::getString(): Argument WordPress#2 ($start) must be a stack pointer which exists in the $phpcsFile object, 8 given.
The error originated in the AbstractClassRestrictionsSniff.php sniff on line 131.
```

The additional defensive coding added in this commit, fixes the issue.

This commit fixes the test failure seen in PR 2499.

The test failure was surfaced due to a new exception in PHPCS (see: PHPCSStandards/PHP_CodeSniffer 524), which will be included in PHPCS 3.11.0.

The test failure highlighted that the above mentioned PHPCS PR needs a follow-up with some extra defensive coding, however, that defensive coding is needed in a part in PHPCS which does the error handling for PHP notices being encountered, i.e. the throwing of `Internal.Exception` errors.

This implied there was also an underlying issue in WPCS causing the `Internal.Exception`, which apparently was only triggered when the fixer was being run.

> Note: the fact that `Internal.Exception`s during a PHPCBF run are being suppressed is a known issue, but fixing that is not that easy, so that definitely won't happen before PHPCS 4.0 (and may not even make it into 4.0). See: squizlabs/PHP_CodeSniffer 2871

Either way, I've looked into the `Internal.Exception` now.
The error was as follows:
```
An error occurred during processing; checking has been aborted. The error message was: PHPCSUtils\Utils\GetTokensAsString::getString(): Argument #2 ($start) must be a stack pointer which exists in the $phpcsFile object, 8 given.
The error originated in the AbstractClassRestrictionsSniff.php sniff on line 131.
```

The additional defensive coding added in this commit, fixes the issue.

)

This commit fixes the test failure seen in PR 2499.

The test failure was surfaced due to a new exception in PHPCS (see: PHPCSStandards/PHP_CodeSniffer 524), which will be included in PHPCS 3.11.0.

The test failure highlighted that the above mentioned PHPCS PR needs a follow-up with some extra defensive coding, however, that defensive coding is needed in a part in PHPCS which does the error handling for PHP notices being encountered, i.e. the throwing of `Internal.Exception` errors.

This implied there was also an underlying issue in WPCS causing the `Internal.Exception`, which apparently was only triggered when the fixer was being run.

> Note: the fact that `Internal.Exception`s during a PHPCBF run are being suppressed is a known issue, but fixing that is not that easy, so that definitely won't happen before PHPCS 4.0 (and may not even make it into 4.0). See: squizlabs/PHP_CodeSniffer 2871

Either way, I've looked into the `Internal.Exception` now.
The error was as follows:
```
An error occurred during processing; checking has been aborted. The error message was: PHPCSUtils\Utils\GetTokensAsString::getString(): Argument #2 ($start) must be a stack pointer which exists in the $phpcsFile object, 8 given.
The error originated in the AbstractClassRestrictionsSniff.php sniff on line 131.
```

The additional defensive coding added in this commit, fixes the issue.

Co-authored-by: jrfnl <[email protected]>