feat(NO-TASK): Bundle parallel-lint so the standard is one dependency

[aaronware]

Adds php-parallel-lint/php-parallel-lint and php-console-highlighter to
require, so taking the standard means taking the toolchain.

The co-occurrence is absolute

Repos requiring linchpin/coding-standards	12
...that also require parallel-lint	12
...that don't	0

There is no case in the org where someone wants the standard without it. And
each spells the constraint differently — ^1.4, ^1.4.0, ^v1.4.0 (stray v)
— so one require here removes a whole class of drift. 11 of the 12 also carry
php-console-highlighter, so that comes too.

Timely: 23 repos are about to adopt the standard as part of moving off the
phpcs/phpcbf/phplint trio. They get one line instead of two.

The argument against, stated plainly

This package is type: phpcodesniffer-standard and parallel-lint isn't a sniff.
Practically it's inert — the installer plugin only scans for rulesets, and the
package already carries a non-sniff require-dev (phpunit/phpunit). I'd take
the small impurity over a second package nobody remembers to add.

If phpstan and php-cs-fixer get standardised too, the cleaner long-term shape is
a linchpin/php-dev metapackage requiring this one plus the tools. That layers
on top without undoing this.

Verified

Against a path-repo consumer requiring only this package:

vendor/bin: parallel-lint  phpcbf  phpcs  sniff  tokenize

Checked 1 files in 0.1 seconds / No syntax error found
The installed coding standards are MySource, PEAR, PSR1, PSR2, PSR12, Squiz,
Zend, WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra, ...

Every standard still registers. composer validate clean.

For existing consumers

No change required — an explicit require alongside is harmless. They can drop
their own parallel-lint line whenever convenient.

feat, so release-please cuts v1.2.0.