Basically, I don't want bindables in `CarouselItem`. It means there
needs to be a bind-unbind process on pooling. By moving these to the
drawable and just updating every frame, we can simplify things a lot.
With the animation logic being external, it was going to make it very
hard to apply the scroll offset when a new panel is added or removed
before the current selection.
There's no real reason for the animations to be local to beatmap
carousel. If there's a usage in the future where the animation is to
change, we can add more customisation to `Carousel` itself.
Also:
- Adds hinting at grouping and header status of items
- Passes through criteria and prepare for grouping tests.
- Makes `Filters` list `protected` because naming clash with `Filter()`
on `BeatmapCarousel`.
- Actually shows scores rather than playlist aggregates (which are
useful... in playlists, where there is more than one item)
- Actually allows scores to be shown by clicking on them
- Doesn't completely break down visually on smaller window sizes
The general appearance is not as polished as the old one in details but
I wanted something quick that we can get out by next weekend.
Also includes the naive method of refetching scores once a new top 50
score is detected. I can add a stagger if required.
With this new order, the logo can be easily moved to display in front of the footer in `SongSelectV2` without breaking experience when footer-based overlays are present. Such overlays (i.e. mod select overlay) will also be dimmed alongside the current screen when a game-wide overlay is open (e.g. settings).
The point is to apply the transitions against a container that's inside of `ScreenFooterButton`, because the `ScreenFooterButton` drawable's position is being controlled by the flow container it's contained within, and we cannot apply the transitions on it directly.