Check handling of attributes on function declaration parameters

[jrfnl]

Setting the scene

PHP 8.0 introduced support for attributes via the #[...] syntax. At this moment, neither PHPCS itself, nor PHPCSExtra contain any sniffs to handle the formatting of attributes.

The PER Coding Standard from FIG, since PER 2.0, outlines a set of rules for attribute formatting to comply with, so using those rules as a starting point would allow for creating an initial set of sniffs to address attribute formatting.

The PER rule

From PER:

For attributes on parameters, if the parameter list is presented on a single line, the attribute MUST be placed inline with the parameter it describes, separated by a single space. If the parameter list is split into multiple lines for any reason, the attribute MUST be placed on its own line prior to the parameter, indented the same as the parameter. If the parameter list is split into multiple lines, a blank line MAY be included between one parameter and the attributes of the following parameter in order to aid readability.

The action

The above rules should probably be covered via pre-existing function declaration sniffs; or at the very least, if a new sniff would be introduced to address this, it needs to be safeguarded that the pre-existing sniff(s) and the new sniff do not create fixer conflicts.

I imagine that the "may include a blank line" part of the above rule could cause fixer conflicts, but there may be more potentially conflicting aspects

It will need investigating which sniff(s) should handle this and whether these sniffs already handle attributes on parameter declarations or not.

The initial outcome should be a list of sniff names for sniffs which handle function declarations and whether these currently ignore/format parameter attributes and if so, whether how this is handled is in line with the PER rules or not.

Bonus points for analyzing the function declaration sniffs in enough detail to be able to advise whether the existing sniff(s) should be updated or whether this should be handled via a separate sniff and where the risks of fixer conflicts are.

The next step after that would be updating the sniffs where needed.

Please note: the initial investigation and the sniff updates do not have to be done by the same contributor. These are separate tasks.