[Documentation] Squiz: Member Var Spacing

[jaymcp]

Description

This PR adds documentation for the Squiz.WhiteSpace.MemberVarSpacing sniff.

Suggested changelog entry

Add documentation for the Squiz Member Var Spacing sniff

Related issues/external references

Part of #148

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the Contribution Guidelines.
• I grant the project the right to include and distribute the code under the BSD-3-Clause license (and I have the right to grant these rights).
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added XML documentation for the sniff.

[jrfnl]

Hi @jon, thanks for working on this.

I've reviewed the PR and have the following feedback/questions:

• Interfaces are not allowed to declare properties, so some of the code samples in the docs are invalid. See: https://3v4l.org/mMMk6
• Is there a particular reason to show examples of each OO structure for each rule/standard ?
  Would using variation, but not repetitiveness work ? What I mean by that is, for instance, for the first standard have just one OO code sample using an class structure, for the second, one OO code sample with a trait, for the third one OO code sample with an anonymous class. What do you think ?
• The second standard, by its nature, includes a code sample for the first rule too. Would combining the first and the second standard be an viable option ? I'm not sure it that would work, but was wondering if you'd considered it/tried it.

[jaymcp]

• Interfaces are not allowed to declare properties, so some of the code samples in the docs are invalid. See: https://3v4l.org/mMMk6

Indeed! Removed in 34203fa.

• Is there a particular reason to show examples of each OO structure for each rule/standard ?
  Would using variation, but not repetitiveness work ? What I mean by that is, for instance, for the first standard have just one OO code sample using an class structure, for the second, one OO code sample with a trait, for the third one OO code sample with an anonymous class. What do you think ?

• The second standard, by its nature, includes a code sample for the first rule too. Would combining the first and the second standard be an viable option ? I'm not sure it that would work, but was wondering if you'd considered it/tried it.

I did originally have the standard & examples for the first two error codes combined (which is where the excessive quantity of examples originated from), but decided to split each error code into its own standard. I guess I've been leaning more towards having separate standard/code_comparison blocks for each error code, but with no real justification for doing so.
I've trimmed the examples down per your suggestion, but am happy to also combine the first two codes into one if you think that will look/read better.

Edit:
I am wondering, though, whether there's a means of marking up a <standard> as relating to a specific error code within a sniff (beyond actually writing it into the description within)?
Found your previous comments addressing similar questions: #317 (comment)

[jrfnl]

Hi @jonmcp Nearly there as far as I'm concerned. Just some small suggestions in-line to have a look at.

[jrfnl]

@jonmcp Thank you for your patience and for working with me to get this one ready. All good now.

I'm going to rebase the PR and will merge once the build has passed.