I had a bit of a struggle getting header traversal logic to work well.
The constraints I had in place were a bit weird:
- Group panels should toggle or potentially fall into the prev/next
group
- Set panels should just traverse around them
The current method of using `CheckValidForGroupSelection` return type
for traversal did not mesh with the above two cases. Just trust me on
this one since it's quite hard to explain in words.
After some re-thinking, I've gone with a simpler approach with one
important change to UX: Now when group traversing with a beatmap set
header currently keyboard focused, the first operation will be to reset
keyboard selection to the selected beatmap, rather than traverse.
I find this non-offensive – at most it means a user will need to press
their group traversal key one extra time.
I've also changed group headers to always toggle expansion when doing
group traversal with them selected.
To make all this work, the meaning of `Activation` has changed somewhat.
It is now the primary path for carousel implementations to change
selection of an item. It is what the `Drawable` panels call when they
are clicked.
Selection changes are not performed implicitly by `Carousel` – an
implementation should decide when it actually wants to change the
selection, usually in `HandleItemActivated`.
Having less things mutating `CurrentSelection` is better in my eyes, as
we see this variable as only being mutated internally when utmost
required (ie the user has requested the change). With this change,
`CurrentSelection` can no longer become of a non-`T` type (in the
beatmap carousel implementation at least).
This might pave a path forward for making `CurrentSelection` typed, but
that comes with a few other concerns so I'll look at that as a
follow-up.
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`.
