Add some more rule rationales

[mildm8nnered]

No description provided.

[SwiftLintBot]

	1 Warning
⚠️	If this is a user-facing change, please include a CHANGELOG entry to credit yourself! You can find it at CHANGELOG.md.

	19 Messages
📖	Building this branch resulted in the same binary size as when built on main.
📖	Linting Aerial with this PR took 0.21 s vs 0.23 s on main (8% faster).
📖	Linting Alamofire with this PR took 0.21 s vs 0.21 s on main (0% slower).
📖	Linting Brave with this PR took 1.07 s vs 1.08 s on main (0% faster).
📖	Linting DuckDuckGo with this PR took 3.62 s vs 3.62 s on main (0% slower).
📖	Linting Firefox with this PR took 1.8 s vs 1.8 s on main (0% slower).
📖	Linting Kickstarter with this PR took 1.07 s vs 1.1 s on main (2% faster).
📖	Linting Moya with this PR took 0.12 s vs 0.12 s on main (0% slower).
📖	Linting NetNewsWire with this PR took 0.41 s vs 0.41 s on main (0% slower).
📖	Linting Nimble with this PR took 0.19 s vs 0.19 s on main (0% slower).
📖	Linting PocketCasts with this PR took 1.11 s vs 1.11 s on main (0% slower).
📖	Linting Quick with this PR took 0.15 s vs 0.16 s on main (6% faster).
📖	Linting Realm with this PR took 0.54 s vs 0.52 s on main (3% slower).
📖	Linting Sourcery with this PR took 0.35 s vs 0.37 s on main (5% faster).
📖	Linting Swift with this PR took 0.65 s vs 0.66 s on main (1% faster).
📖	Linting SwiftLintPerformanceTests with this PR took 3.8 s vs 3.83 s on main (0% faster).
📖	Linting VLC with this PR took 0.31 s vs 0.3 s on main (3% slower).
📖	Linting Wire with this PR took 2.39 s vs 2.36 s on main (1% slower).
📖	Linting WordPress with this PR took 1.69 s vs 1.72 s on main (1% faster).

Here's an example of your CHANGELOG entry:

* Add some more rule rationales.  
  [mildm8nnered](https://github.com/mildm8nnered)
  [#issue_number](https://github.com/realm/SwiftLint/issues/issue_number)

note: There are two invisible spaces after the entry's text.

Generated by 🚫 Danger

[Copilot]

Pull Request Overview

This PR adds rationale documentation to several SwiftLint rules, explaining why certain coding patterns are preferred over others. The rationales primarily focus on performance benefits and API modernization.

Key Changes

• Added performance-related rationales to five rules that recommend using more efficient alternatives
• Added API modernization rationale to the legacy NSGeometry functions rule

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
EmptyCountRule.swift	Added rationale explaining O(1) vs O(n) performance difference between isEmpty and count
ContainsOverRangeNilComparisonRule.swift	Added rationale explaining early exit benefits of contains over range(of:)
ContainsOverFirstNotNilRule.swift	Added rationale explaining early exit benefits of contains over first(where:)
ContainsOverFilterIsEmptyRule.swift	Added rationale explaining early exit benefits of contains over filter
ContainsOverFilterCountRule.swift	Added rationale explaining early exit benefits of contains over filter
LegacyNSGeometryFunctionsRule.swift	Added rationale explaining modern API benefits and cross-platform support

[Copilot]

The rationale incorrectly mentions filter when it should refer to first(where:) and firstIndex(where:). The rule is about these methods, not filter. Update the rationale to correctly explain that first(where:) and firstIndex(where:) already support early exit, but using contains is more semantically clear when you only need to check for existence.

Suggested change

	`filter` always needs to scan the entire collection, whereas `contains` can exit early as
	soon as a match is found.
	While `first(where:)` and `firstIndex(where:)` already support early exit, using `contains` is more semantically clear when you only need to check for the existence of an element matching a predicate.