Tests: minor cleanup

Follow up on PR 305. By setting the minimum PHPUnit 9.x version to 9.3, we no longer have to backfill the missing Xdebug constants.

Add "static analysis" Composer keyword

As per https://getcomposer.org/doc/04-schema.md#keywords by including "static analysis" as a keyword in the `composer.json` file, Composer 2.4.0-RC1 and later will prompt users if the package is installed with `composer require` instead of `composer require --dev`. See https://github.com/composer/composer/pull/10960 for more info.

Merge pull request #340 from PHPCSStandards/controlstructures/getdeclarescopeopenclose-more-tests-and-handle-php-close-tag

ControlStructures::getDeclareScopeOpenClose(): support closing the declare statement with PHP close tag

ControlStructures::getDeclareScopeOpenClose(): support closing the declare statement with PHP close tag

... and also add tests to confirm that "multi-directive" statements are handled correctly.

.gitattributes: update for newly added config files

GetVersionTest: update for release of PHPCS 3.7.1

GH Actions: add new workflow to automate repeated task

The `GetVersionTest` test class contains a constant which should be set to the PHPCS version number of the latest release.

Until now, this version number would be updated manually on an ad-hoc basis.

This workflow automates these updates and will automatically create a PR to update the version number whenever PHPCS has had a new release.

The workflow will run:
* Every night via a cronjob.
    Note: this does mean the workflow will be automatically disabled if there would be no activity in the repo for more than two months.
* On pull requests which update the workflow.
* And can be manually triggered if needed.

Includes removing the update reminder from the release checklist.

See 259, 286, 324.

Operators::isUnaryPlusMinus(): allow for match control structures

The double arrow in PHP 8.0 match control structures has its own `T_MATCH_ARROW` token.
This token needs to be taken into account when determining if a plus/minus token is unary or arithmetic.

This token was introduced in PHPCS 3.6.0 and will be tokenized as `T_DOUBLE_ARROW` for older PHPCS versions.
The method already looks for `T_DOUBLE_ARROW` before the operator, so checking for `T_MATCH_ARROW` solely based on token type will handle match arrow tokens in a PHPCS-cross-version compatible manner.

Ref: squizlabs/PHP_CodeSniffer 3653

Co-authored-by: Jaroslav Hanslík <kukulich@kukulich.cz>

New (internal) Cache and NoFileCache classes + implement use of these

Adjust the GH actions test workflows to run the complete test suite once with the cache turned on and once with the cache turned off.

The test run with caching turned on will run the tests twice and only run the tests which don't need isolation.
This should safeguard that the cache does not negatively influence sniff results.

The code coverage job will (should) run with caching turned _off_ to prevent tests not reaching all code paths due to cached results from previous tests short-circuiting things.

Note: the effect of caching on the test suite will be minimal as most tests will only execute a function once for a particular input/code snippet. Still good to safeguard/double-check though.

This commit sets up a mechanism in the test `bootstrap.php` file to turn the cache on/off depending on an environment variable, which can be set from within a `phpunit.xml` file or on the OS-level.

This allows for running the tests both with caching turned on, as well as with caching turned off.

By default, the tests will run with caching turned **off**.

Being able to run the tests with both settings will allow for:
* [Caching off] Making sure that all code paths can be reached (code coverage check). Caching being enabled could prevent some code paths from being tested.
* [Caching on] Making sure that caching does not (negatively) impact the actual results of the functions.

Depending on the size of the text string, this function _could_ become pretty slow/performance intense, which is why I'm implementing caching for it.

Includes a dedicated test to verify the cache is used and working.

These are easily the most used functions as well as the slowest functions (when dealing with large arrays/lists).

While this commit already implements the use of the new `Cache` class, further improvements are still needed and will be pulled in a follow-up PR.

Note: code coverage for these functions _may_ go down a little due to the multiple exit points in the functions. I'm not concerned about that as that - again - will be addressed in the follow-up PR.

Includes a dedicated test to verify the cache is used and working.

While most list only involve a few assignment, for more complex and nested list structures, splitting the list into the individual assignments can tax performance, which is why I'm implementing caching for it.

Includes a dedicated test to verify the cache is used and working.

While this function will generally be _fast_ for array entries _with_ a double arrow, it will be _slow_ for array entries without a double arrow, especially if the contents of the array item contains a lot of tokens as the fact that the array item does not have a double arrow can only be determined when the end of the array item has been reached.
With this in mind, I'm implementing caching for it.

Includes some minor tweaks to the exit routes of the function to ensure that the cache will always be set.

Includes a dedicated test to verify the cache is used and working.

Depending on whether or not group use or multi-use statements are used, this method can involve sufficient token walking to make caching relevant.
Especially when keeping in mind that this function will likely be used a **_lot_** in the near future as part of the namespace resolution functionality, so retrieving the results via the cache instead of executing the same logic dozens of times for a file, seem prudent.

Includes a dedicated test to verify the cache is used and working.

This method finds the end of a potentially multi-line text string.
While most text strings are short and even multi-line ones are often only a few lines, some can be thousands of lines long.
With that in mind, I'm implementing caching for this method.

I've considered also applying caching for the `TextStrings::getCompleteTextString()` method, but as - in the case of thousands of lines long text - that would take a huge chunk of memory, I've decided against it.
Caching the "end token" of a multi-line text string should sufficiently improve performance.

Includes a dedicated test to verify the cache is used and working.

While most function calls only involve a few parameters, splitting out an array into the individual array items can be very processing intense and will slow things down considerably when multiple sniffs each need the break down of the same array.

With this in mind, I'm implementing caching for it.

The saved cache can be quite large for calls to this function, at the same time, the trade off performance-wise is worth it in this case IMO.

Note: as this function can be called with a `$limit`, we need to be able to distinguish between "limited" results and "full" results, but should also take advantage of available "full" results when a consecutive function call tries to retrieve a "limited" result.

The implementation takes this into account, though the situation where a "limited" result was previously retrieved (and cached), and new "limited" call is made with a _lower_ limit currently does not take full advantage of the available cache. This is possibly an improvement which can still be made in the future.

Includes a set of dedicated tests to verify the cache is used and working, including testing specifically how the cache is set and used when the `$limit` parameter has been passed.

This method searches up in a file to try and find an applicable namespace declaration.
As non-scoped namespace declarations are often at the top of the file, this can involve a **_lot_** of token walking, which is why I'm implementing caching for it.

Includes some minor tweaks to the exit routes of the function to ensure that the cache will always be set when the token passed is not in a scoped namespace declaration.

Includes a dedicated test to verify the cache is used and working.

While arrow functions are generally only small snippets of code, as they don't always have a clear "end token", determining whether something is an arrow function and retrieving the relevant open/close tokens can be token-walking intensive, which is why I'm implementing caching for it.

Note: the results will only be cached for the backported functionality. When using a more recent PHPCS version, the cache code will only be reached in the case of parse errors.

Includes a dedicated test to verify the cache is used and working.

As `declare` constructs using alternative syntax can be long, determining the scope opener/closer can involve a lot of token walking, which is why I'm implementing caching for it.

Includes some minor tweaks to the exit routes of the function to ensure that the cache will always be set when the `T_DECLARE` token doesn't natively have a scope opener/closer assigned.

Includes a dedicated test to verify the cache is used and working.

Includes:
* Additional tests to cover this change on the off-chance that someone will use this functionality in a non-test situation.
* Making sure that the tests related to the `[NoFile]Cache` classes will always run with caching turned **on** as running the cache functionality tests without caching enabled is a little pointless (and would fail the tests).

... to allow for caching the results of processing intensive utility methods.

The `Cache` class is intended to be used for utility functions which depend on the `$phpcsFile` object.
The `NoFileCache` class is for file-independent functions.

Use selectively and with care as the memory usage of PHPCS will increase when using these caches!

Includes full set of tests to cover this new functionality.

These new tests have been added to the `RunFirst` test suite to prevent the cache setting and clearing done in these tests from interfering with the rest of the tests.

Based on a similar class I wrote for the Requests library.

If/when that class get published as a package, this class should be removed in favour of the package.

Merge pull request #334 from PHPCSStandards/feature/tests-minor-tweaks-to-allow-for-repeat-test-runs

Tests: minor tweaks to allow for running tests on repeat

... using the PHPUnit `--repeat` option.

Note: this option was already available in PHPUnit 4.x, so can be safely used for this codebase.

The changes made:
* Prevent "constant already defined notices" on repeated test runs.
* Prevent a file from not being tokenized on repeated test runs.

Ref:
* https://phpunit.readthedocs.io/en/9.5/textui.html

Tests: use parameter names in data provider test cases

... when the data set array contains more than one item.

This is done to lower the cognitive load when reading the tests.

Includes:
* Renaming a couple of parameters for more consistency.
* Renaming data provider sub-array keys if they didn't match the parameter names of the test function.

Note: this changeset excludes the `isShortArrayOrList` tests. Those tests will be addressed separately in the refactor of those methods.

Hoping I've caught everything, but not claiming completeness.

QA/Tests: various code coverage tweaks

... for code which is only in place as defensive coding, but shouldn't be reachable under normal circumstances.

The functions being tested in these three test classes all use function local `static` variables for optimization.

Having the function local `static` variable will often prevent code coverage from being recorded correctly for the code as the code for setting the static will only be run when the function is first called, which may not be in the dedicated test for the function, so it makes code coverage recording highly dependant on the order in which tests are run.

In these three cases, I do believe the function local `static` variable is justified (for the time being, benchmarking should be able to determine for sure at some point in the future).

To still prevent missed lines in the code coverage reports, I'm moving the tests for these three functions into a separate test suite, which will run first.
This should ensure the code which sets the static will be run first when the dedicated tests for these methods are run and should allow the correct registration of code coverage for this code.

Mind: if at some point the `executionOrder` configuration would be added to the config/enabled, it needs to be verified how that behaves in combination with multiple test suites. But that's for later.

Ref: https://github.com/sebastianbergmann/php-code-coverage/issues/913

While the feedback shown in the `setup-php` step is awesome, it doesn't show the version of Xdebug used when running code coverage, while, in case of issues, the version number of Xdebug is crucial to know.

This extra step allows for that information to always be available.

I've only added the step to the code coverage job though as that's the only one for which the Xdebug version is relevant.

Merge pull request #328 from PHPCSStandards/passedparameters/hasparameters-account-for-parent-tokenization-change

PassedParameters::hasParameters(): account for upstream tokenization change for `parent`

Upstream PR squizlabs/PHP_CodeSniffer 3546, which is included in PHPCS 3.7.0, changed the tokenization of the `parent` keyword in `new parent()` from `T_STRING` to `T_PARENT`.

This has consequences for the `PassedParameters::hasParameters()` method and associated methods:
* The `Collections::parameterPassingTokens()` method will now need to include the `T_PARENT` token.
* The underlying `Collections::functionCallTokens()` method should as well.
* The `PassedParameters::hasParameters()` method now needs to allow for the `T_PARENT` token potentially being used as part of a `new parent()` function call.

This commit fixes all that up.

Includes additional unit tests to safeguard it all (and some more).