Document the ability to execute the main plugin functionality directly

[Potherca]

Problem/Motivation

The main functionality of this plugin (installing a custom code sniff) can be called separately (see isue #4).
However, this functionality has not (yet) been documented. It could be useful for users to be made aware of this feature in the documentation.

Expected behaviour / Actual behaviour / Steps to reproduce

Does not apply

Proposed changes

Document what the future is and how it can be used.

[Wirone]

Before making docs consider refactoring of plugin's class and entry point method's names. In my opinion they're not descriptive, especially the latter.

Both (class and method) should be named in a way like Incenteev\\ParameterHandler\\ScriptHandler::buildParameters or Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache.

Maybe Dealerdirect\\Composer\\Plugin\\Installers\\PHPCodeSniffer\\PHPCompatibilityPlugin::installSniffs?

For backward compatibility you can then extend Dealerdirect\Composer\Plugin\Installers\PHPCodeSniffer\PHPCompatibilityPlugin with Dealerdirect\Composer\Plugin\Installers\PHPCodeSniffer\Plugin and use Plugin::run() to call PHPCompatibilityPlugin::installSniffs(). In future versions this could be deprecated and removed.

[Potherca]

Valid point, will clarify the method name. As naming a thing is hard, @frenck: do you have any quams about PHPCompatibilityPlugin::installSniffs()?

[frenck]

@Potherca nope, I agree with @Wirone.
I feel like we need another separate issue for this.

[Wirone]

Now when I think of it, it should not be named PHPCompatibilityPlugin since it's not only about PHPCompatibility, but any custom standard, right?

So maybe CustomStandardsPlugin::installStandards()?

We all know phrase about naming and invalidating cache 🤣

[Potherca]

Added documentation to the README, leaving the method/class rename for another issue.

[Potherca]

Resolved by #29 will be included in the upcoming v0.4 release.