Add support for PSR-4/`composer dump-autoload` testing

[TravisCarden]

Q	A
Version	v1.16.0
Bug?	no
New feature?	yes
Question?	no
Documentation?	yes
Related tickets	n/a

I just discovered that composer validate will pass even if there are PSR-4 problems. That's not the fault of GrumPHP, but it may be misleading.

Steps to reproduce/Result: Given a Composer project with PSR-4 configured and GrumPHP installed, just put a class file in the wrong directory and...

# `composer validate` reports nothing and returns a success status code.
$ validate; echo $?
./composer.json is valid
0

# `composer dumpautoload` reports the error and returns a failure code given the `--strict-psr` option.
$ composer dumpautoload --strict-psr 1> /dev/null; echo $? # (Silence stdout for clarity.)
Class Example\Good located in ./src/Bad.php does not comply with psr-4 autoloading standard. Skipping.
1

Proposal: Either add a new task (or an option to the existing composer task), to use composer dumpautoload to check PSR-4 violations.

[veewee]

Hmm interesting. The dump autoload changes files, which might not be the wanted scenario here. Maybe it could make sense for composer to add this check to the validation command somehow?

[TravisCarden]

^ I've proposed a dumpautoload --dry-run option. 🙂

[TravisCarden]

Update: The above-proposed dumpautoload --dry-run option has been committed upstream and is scheduled for release in Composer 2.6.