Library: add overview column

[ronso0]

continuation of #13638
This is now based on @ninomp's initial POC commit 80d8b5f
from https://github.com/ninomp/mixxx/commits/overviewsinlibrary-rebased/
(incl. the fix from #14150 )
I addressed @Swiftb0y's review and a lot evolved anyway.

• the library shows a pseudo-mono view (hardcoded in OverviewCache::prepareOverview), though with a bit of refactoring this could be made optional
• overviews are rendered as soon as track analysis finished (loading tracks not required)
• overviews (decks and library) are updated when the library row height, overview type or the Normalize/visual gain options are changed, and the cache is cleared
• the signal colors can be set in the <Library> node exactly like in the waveform templates (<Visual> widget)
• WOverView and OverviewDelegate use the same renderer for all types which I extracted from WOverview to src/waveform/renderers/waveformoverviewrenderer
  (I adopted the RGB simplifications made by @Nino MP, and simplified the others, too)
• there's an OverviewCache which holds the images sized for the overview column

Ideas / Nice to have

• show analyzer progress / partial painting like in decks
• add mono-mixdown / stereo option
• click Overview column header to sort by 'has overview'
• cleanup / optimize draw functions in WaveformOverviewRenderer
• some sort of analysis progress indicator in the library? (though I think partial rendering would be distracting)
• implement preview interface: click to select, click position to preview
• show cue markers?

[ronso0]

Draft until CI is happy.
I'll rebase and force-push, so please don't start reviewing yet.

[ronso0]

I took a second look and polished it a bit.
Ready for review!

[daschuer]

Left some comments, not tested yet.

[daschuer]

We should not use a direct connection here, this may cause headaches later. See my other comment.

[acolombier]

@ronso0 I'm marking this PR as draft, but feel free to make active once everything is ready for another round of tests!

[ronso0]

Sure, I'm in no hurry here, and apparently there's not too much interest.
This has been ready for testing for a few weeks already and the technical reviews have been adressed in main already, too.
Will merge main soon.

[acolombier]

there's not too much interest

I'd love to see this feature in! But equally spotted a lot of reviewer involved with this feature, and the few PR iteration so I didn't want to create a "too many cooks" problem.

This has been ready for testing for a few weeks already

Will test soon then

[fwcd]

Very interested in seeing this too! Gave the macOS build a quick spin and couldn't find any obvious performance regressions, seems to run pretty snappily. Interestingly, this seems to be mostly unaffected from #14089.

[acolombier]

Tested on Linux (Fedora/Wayland) and works great! No performance impact, run smoothly. Only thing that would be great to change is to remove the sorting capability on the column as it has no effect (and probably shouldn't have any), but that's minor and happy to merge without this.

[fwcd]

I actually stumbled upon this and had a funny idea: What if sorting the overview column would sort by average energy or something? Would probably be terribly slow to compute given that waveforms are loaded lazily and introducing something like that would probably be better modeled as a separate analysis/column (#12131) 😄

[ronso0]

and apparently there's not too much interest.

Okay okay so I was wrong 😄
Thanks for testing!
Yes it runs pretty smooth

Credits go to @ninomp who did most of the work here!

[ywwg]

I love this feature and have been running it in my personal builds! really interested in this getting in

[ronso0]

Alright then, I'll squash and rebase, r just squash and merge main?
What's preferred here?

(I think the last remaining review comment (Qt::DirectConnection is obsolete after merge/rebase)