Defer rollover checks while generating selection decorations

[abcdefg30]

In a profiling run a few days ago the rollover check took around 3% of the total CPU time. I wasn't able to reproduce that number in subsequent runs however. (It evened out at ~0.5%.) The changes in this PR still more than halved the time spent in the method (~0.2%), but I wouldn't be opposed to just closing this if the code changes seem to "ugly" for that speedup.
Fwiw, it does make sense to me to not perform those checks for people who use AlwaysShow for selection bars. (And with the changes in the PR we'll also not perform them for some cases with DamageShow.)

[pchote]

This doesn't seem too ugly, IMO.

[pchote]

What seems to actually be going on here is that Selection.rolloverActors is being assigned with an enumerator result from a LINQ expression, which ends up being reevaluated every time something wants to check RolloverContains, when it could instead be using a concrete list.

Can you please check whether keeping SelectionDecorationsBase as it is and instead calling SetRollover(rollover.ToList()) gives an even larger perf improvement?

[pchote]

It may be even better still to pass the IEnumerable but then keep a list inside selection that we clear and repopulate with .AddRange(rollover) instead of reallocating a new list every tick.

[pchote]

Something like 61a2b84

[abcdefg30]

The RolloverContains function dropped to ~0.0% now.

[penev92]

Code looks sensible, the explanations paint a good picture and I'm going to trust your profiling.

[penev92]

Changelog