reference issue #104 from @aik099

I've updated description of #104 several times, so make sure you've addressed all sniffs.

• CastSpacingSniff (removed, see issue Remove sniffs in favor of build-in ones #104)
• DisallowSpaceIndentSniff (removed, see issue Remove sniffs in favor of build-in ones #104)
• MemberVarSpacingSniff rule (removed)
• SemicolonSpacingSniff (removed, see issue Remove sniffs in favor of build-in ones #104)
• ObjectOperatorIndentSniff (removed)
• LowerCaseConstantSniff (removed, see issue Remove sniffs in favor of build-in ones #104)
• ElseIfDeclarationSniff (see issue Remove sniffs in favor of build-in ones #104 )
• Review ruleset.xml annotation for possible elimination of currently included sniffs without the need for a custom sniff https://github.com/squizlabs/PHP_CodeSniffer/wiki/Annotated-ruleset.xml
• SpaceAfterCastSniff (doesn't this conflict with the CastSpacingSniff sniff? see issue Remove sniffs in favor of build-in ones #104)

- [ ] SuperfluousWhitespaceSniff (see issue #104 )
- [ ] ConcatenationSpacingSniff (see issue #104 )

For removals related to PHPCS-2 development branch see PR #101

Nice catch with these task checkboxes that GitHub have. Would be much easier to track now.

@mbabker Do you think it would be better to break this PR up into multiple PRs for each file removal and rule inclusion pair? currently it would be about 7 PRs with consideration for 3 others.

Truthfully, it doesn't matter much to me. As long as I (or someone) can make sense of it all when sitting down to go through it; if it's clearly explained somewhere I'm not too picky about it being one PR.

@mbabker My thought was it might be easier for you (or someone) to sit down and look at each one individually and approve one here and there; rather than the larger time commitment to review as one big PR.

But taking your advice for this to be "clearly explained somewhere," I have updated the PR description to cover the intent and current inclusions of this PR.

@mbabker shall we finish this 1.x PR or close in favor of "leaving the 1.x structure in a "minimal maintenance" type of state." ?

Ya, let's just leave things alone. The whole "if it ain't broke" thing. Better for us to put our code focus on the 2.x ruleset at this point.