Filter overlay plane candidates

[Drakulix]

An attempt at smarter plane usage.

If we end up compositing on the gpu anyway, it rarely makes sense to use hardware compositing as well, given the render time will be basically the same no matter if we composite 6 or 5 surfaces.

However if only a handful of elements are actually updating, we could potentially skip software composition all together if those would be placed on hardware planes. This ends up happening very rarely though, as from cosmic-comp's perspective the shell components are usually the first in the render-order, making them hug the hardware composition chain.

To fix this, lets introduce some filtering for viable scanout targets. We expect targets with a rather constant or high refresh rate to be good candidates as frequent updates would frequently require re-rendering otherwise.

As such we start tracking the refresh rate of new surfaces (f82864a) and then start filtering surfaces for scanout to those hitting at least 20 fps (e.g. movie players with potentially only 24 FPS) (d646992).

Additionally we fix normal desktop applications in fullscreen mode with vrr set to "automatic" by only skipping cursor updates, if the application in question hits at least 30fps consistently (d493151).

Last but not least we also save on atomic tests by skipping overlay plane usage during animations (93c5d2b) (and moving windows - 1287f32) as re-positioning planes can be quite costly in terms of time for the atomic checks. Together with not testing as many candidates in the first place this brings down our frame times, hopefully addressing the flickering issues some people are seeing at higher refresh rates, while more consistently hitting the scanout paths for applications that actually make good use of it.

Draft while more testing is happening and while the required smithay changes are still work in progress.

[Drakulix]

Already, I have not seen any issues with this on two systems driving this for about a week. Lets merge.