NoLeadingUnderscores: allow leading-underscore backing properties

[luancamara]

Resolves #1150.

What

The opt-in NoLeadingUnderscores rule flags a backing property like _count even when a non-underscored sibling property count exists in the same type:

struct Counter {
  private var _count: Int = 0
  var count: Int { _count }   // `_count` was flagged
}

Using a leading underscore to name a backing store for a same-named property is a common, intentional pattern, so this exempts it from the rule. This matches the carve-out @allevato agreed to in the issue discussion, and is unconditional (no new configuration option).

How

visit(_:IdentifierPatternSyntax) now skips the diagnostic when the name starts with _ and a property whose name is the same without the leading underscore is declared directly in the same MemberBlock. The check walks up from the pattern to its enclosing type member block and scans sibling property declarations — it's stateless and localized.

Scoping decisions (each covered by a test):

• Only properties that are direct members of a type/extension qualify; local variables and top-level bindings still flag.
• The counterpart must be a property — a method named count does not exempt _count.
• Matching is limited to the same member block, so a counterpart declared in a separate extension is not matched (kept out of scope for simplicity; happy to extend if desired).

Testing

• Added cases to NoLeadingUnderscoresTests: backing property allowed, non-property counterpart still flags, scoped to the same type, and locals not exempt. All existing cases still pass.
• swift test passes.
• Ran swift run generate-swift-format to update Documentation/RuleDocumentation.md for the rule's new documentation comment. No visit methods were added or removed, so the generated pipeline/registry/name-cache are unchanged.