Move the SyntaxTree and SemanticModel action based analyzers to respect context.FilterSpan

[mavasani]

Closes #67888
Follow-up to #67818

Performance measurements

Summary

• SyntaxTree analyzers: Decent performance improvements seen in this PR for the syntax analyzers. Note that majority of performance benefit was already fetched from Add FilterSpan API to analyzer contexts #67818, which moved our slowest syntax analyzer (IDE0055 - formatting analyzer) to respect context.FilterSpan

• SemanticModel analyzers: Pretty significant performance improvements seen in this PR for the semantic model action analyzers. See screenshots below

Performance screenshots info:

• Left image: Using CodeStyle analyzer package built from main branch
• Right image: Using CodeStyle analyzer package built from this PR branch

SyntaxTree action analyzers

SemanticModel action analyzers

All analyzers (excluding SymbolStart analyzers)

[mavasani]

This is the only compiler change in this PR

[CyrusNajmabadi]

So conceptually, i'm 100% behind this. But hte pattern is so common, and so clunky, it would def benefit from some helpers/extensions.

I also think it's worth discussing making the value non-nullable, and just having the span be the full file for the non-lightbulb case. Then the consumption side simplifies a ton.

[CyrusNajmabadi]

LGTM. I'd like @sharwell's thoughts on if FilterSpan should be nullable or not. However, that's def not blocking, and this PR does implement the approved design, so that convo can happen in parallel.

I'm on the fence. I hear the point about the analyzer doing something different if the span is null or not. But that seems equiv to the analyzer doing something different if the span if the full-span of the compilation unit or not.

GIven that everyone who uses the span effectively does so to see what's in it, or do an intersection test, then null doesn't seem useful. But i'm ok either way :)