Create a `type` for `phpcs-coding-standard`.

[beporter]

It's possible to create a custom composer type that knows to install itself in a sub-folder of the squizlabs/php-codesniffer package. When a composer package for a Coding Standard defines this type in its own composer.json file, it'll be placed in the correct place without requiring the consuming project to run phpcs config-set installed_paths foo/bar.

In other words, in loadsys/loadsys_codesniffer:composer.json:

  "name": "loadsys/loadsys_codesniffer",
  "type": "phpcs-coding-standard",
  "require": {
    "loadsys/composer-plugins": "@stable",
    "squizlabs/php_codesniffer": "@stable"
  }

Then in consuming projects' composer.json:

  "require": {
    "loadsys/loadsys_codesniffer": "@stable", 
  }

Basically, this repo should include a composer installer for the type phpcs-coding-standard that does one of two things:

1. Installs any folder in the current repo containing a ruleset.xml directly into vendor/squizlabs/php_codesniffer/CodeSniffer/Standards/ (where phpcs will "know" about it without phpcs config-set installed_paths)

2. Create, or parse and supplement, vendor/squizlabs/php_codesniffer/CodeSniffer/CodeSniffer.conf to include an installed_paths entry that includes the path to the current repo automatically. This file is already unique per-project, so it'd probably be okay to do the same thing as Cake plugins do and simply add our new coding standard to it automatically. That's a regular PHP file that normally looks like this:

   <?php
    $phpCodeSnifferConfig = array (
     'installed_paths' => 'vendor/cakephp/cakephp-codesniffer,vendor/loadsys/loadsys_codesniffer/',
   )
   ?>

This would essentially solve loadsys/ComposerPlugins#1, and allow us to abandon that repo entirely. There is probably composer plugin code in that fork that we can replicate and modify here to get us 90% of the way there.