Fix #18: Correct extensions not scanned, allow extensions to be overridden

[danepowell]

Fixes #18 by removing the list of extensions to scan from our rulesets. Users must now specify the extensions to scan via the --extensions arg or in phpcs.xml.

I think this should be part of a minor release, since the effects of the breaking change are identical to the bug being fixed (i.e. .module files silently failing to be scanned). The release notes just need to call out this change and the need to manually specify extensions going forward.

[wu-edward]

@danepowell I just tested as a patch to my BLT 13 project, and now module files are sniffed as expected.

I don't have an opinion on whether it's a minor release, as I can see issues either way.

[TravisCarden]

Wow. Nice to see this come up again just in time to celebrate the three-year anniversary of the upstream bug report. 😳 I guess they did say it won't be properly fixed until PHPCS 4.0. Oh well.

This seems like a fine solution to me. Your assessment of the impact of the change seems right to me, @danepowell: a minor release with a clear callout in the release notes seems good.

I just have one suggestion: I think we can simplify the configuration for the end user by putting the rule selection and extensions in the same place like this:

<!-- Uncomment your chosen standard and the filename extensions corresponding to it. -->
<!-- @see https://github.com/acquia/coding-standards-php/issues/18 for background on filename extensions. -->
<rule ref="AcquiaDrupalStrict"/><arg name="extensions" value="php,module,inc,install,test,profile,theme,css,info,txt,md,yml"/>
<!-- <rule ref="AcquiaDrupalTransitional"/><arg name="extensions" value="php,module,inc,install,test,profile,theme,css,info,txt,md,yml"/> -->
<!-- <rule ref="AcquiaPHP"/><arg name="extensions" value="php,inc,test,css,txt,md,yml"/> -->

Then they just uncomment the one line they want. What do you think?