Apply minor changes to the syntactic sugar rewrite

[jpsim]

I was late in reviewing #3866, so I reviewed after it merged and am suggesting some minor changes here.

• Improve docstrings for StringView+SwiftSyntax.swift
• Move changelog entry to correct section & reword
• Change parameter type from Int to ByteCount
• Move AbsolutePosition / ByteCount conversion to internal API
• Only warn once if syntax tree cannot be parsed
• Move Syntactic Sugar examples to a dedicated file
• Change SyntacticSugarRuleVisitor from SyntaxAnyVisitor to SyntaxVisitor
• Add SugaredType enum to help with the implement SyntacticSugarRule

[SwiftLintBot]

	1 Warning
⚠️	This PR may need tests.

	12 Messages
📖	Linting Aerial with this PR took 1.0s vs 0.98s on master (2% slower)
📖	Linting Alamofire with this PR took 1.11s vs 1.11s on master (0% slower)
📖	Linting Firefox with this PR took 4.14s vs 4.14s on master (0% slower)
📖	Linting Kickstarter with this PR took 7.44s vs 7.44s on master (0% slower)
📖	Linting Moya with this PR took 4.37s vs 4.37s on master (0% slower)
📖	Linting Nimble with this PR took 0.4s vs 0.4s on master (0% slower)
📖	Linting Quick with this PR took 0.17s vs 0.17s on master (0% slower)
📖	Linting Realm with this PR took 10.45s vs 9.9s on master (5% slower)
📖	Linting SourceKitten with this PR took 0.33s vs 0.33s on master (0% slower)
📖	Linting Sourcery with this PR took 2.03s vs 2.03s on master (0% slower)
📖	Linting Swift with this PR took 3.15s vs 3.15s on master (0% slower)
📖	Linting WordPress with this PR took 7.39s vs 7.4s on master (0% faster)

Generated by 🚫 Danger

[jpsim]

@PaulTaykalo looks like my changes unintentionally fixed some violations, but I think that's actually better, since the ones that were previously being flagged as violations were initializers like Array<String>(repeating: ..., count: ...) which shouldn't be violations in my opinion since [String](repeating: ..., count: ...) isn't in the spirit of the rule. Same for Optional: Optional<SwiftStringObject>(SwiftStringObject(value: ["bye"]))) vs SwiftStringObject?(SwiftStringObject(value: ["bye"]))) which I'm not even sure is legal Swift.

[PaulTaykalo]

In this case, I suggest adding these examples in non-triggering rules. So those will be documented

[jpsim]

I still think this rule shouldn't apply to initializer cases, but doing that consistently will be more work, so I'll land these internal changes first.

I believe I've reverted the change and if OSSCheck confirms, I'll merge.

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (master@83a8687). Click here to learn what that means.
The diff coverage is 89.33%.

@@            Coverage Diff            @@
##             master    #3915   +/-   ##
=========================================
  Coverage          ?   92.57%           
=========================================
  Files             ?      439           
  Lines             ?    22156           
  Branches          ?        0           
=========================================
  Hits              ?    20511           
  Misses            ?     1645           
  Partials          ?        0           

Impacted Files	Coverage Δ
...LintFramework/Extensions/SwiftLintFile+Cache.swift	79.87% <27.27%> (ø)
...ntFramework/Extensions/ByteCount+SwiftSyntax.swift	100.00% <100.00%> (ø)
...tFramework/Extensions/StringView+SwiftSyntax.swift	100.00% <100.00%> (ø)
...tLintFramework/Rules/Idiomatic/ForceCastRule.swift	100.00% <100.00%> (ø)
...Framework/Rules/Idiomatic/SyntacticSugarRule.swift	96.89% <100.00%> (ø)

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more