Meta tracking issue: "Infinite Scroll" smooth + "ratcheting" scrolling month/multiweek view

This ticket here is the "ponies on rainbows" endgame successor to issue #1 (closed) which could be considered merely a stepping stone / intermediate implementation (ticket no1 would allow doing an initial backend implementation and very simple UI, without having to worry about the whole supporting GTK UI widgetry for high-performance infinite smooth scroll with animations and touch+scrollwheel+keyboard support). Edit: the intermediate "ticket no1" approach is not needed anymore! But useful to look at if you want to learn about the usage scenarios/UX motivations behind all this.

Why this matters

In terms of UX, this is the "ultimate" infinite month view, freed from the artificial physical-paper-like boundaries of a "month": it lets you use it as a traditional month view if you want, or use it as a multi-week "only the weeks ahead" view, and go up/down as you please on a week-by-week basis.

This is a more "optimal" solution than #1 (closed), because it avoids requiring multiple "month vs multi-week" view types, it simply provides one unified and flexible continuous timeline of weeks in a grid, that is no longer chained to the metaphor of physical paper calendar "pages" and allows reducing the amount of widgets and interactions needed in the UI. Compared to the "lazy" approach of a static "Next 3 weeks" separate view, it is more complex to design and implement (it has a lot more details you need to "get right", whether in terms of UI representation or in terms of kinetics management), but the results are way, way better. It also forces us to optimize performance to make this possible.

Others have also thought about this "infinite scrolling timeline" idea in the past, and other calendaring apps out there have implemented it. It's an elegant solution.

Solving this also solves a ton of other technical/architectural issues, and UX issues (see some of the related ones linked below).

Proposed user interaction & UX

As of 2023, my idea now is that the scroll behavior should be per-week (instead of per-month) and smooth, but also behave like a "ratchet" mechanism, i.e. it "clicks into place" like a "wheel of fortune", "coverflow", or rubberband:

• When scrolling with a traditional mousewheel (with discrete "clicks") or keyboard (↓/↑ arrow keys), it should go up/down 1 calendar row (or left/right one column, in weekview, when using the ←/→ keys or Shift+mousewheelscroll) per "mousewheel ratchet click(s)", with a smooth animation that ends with a perfectly aligned week row everytime you finish spinning the mousewheel (or keyboard keys); like a ratchet, but actually double-sided.
• With an infinite scrollwheel (like some mice have, either by default or as a mode), touchpad/trackpad, or touchscreen swiping/gestures: same thing, but the ratchet behavior would only happen once kinetic scroll movement has ended (or influencing the end of the kinetic movement to "round up" the target destination), to allow free scrolling until it clicks into place. In other words, it would be dependent on the position where the user stops the wheel/swipe.
• A tricky part is ensuring this stays in place when resizing the window height, instead of creating "half-rows"...
• #1064 : user configurable amount of rows in month view. Old description:

The height/number of rows shown on screen could be adjusted with pinch zoom and ctrl+scroll like in the week view, but this could be tricky to deal with because it would also need a ratcheting mechanism... a simpler way could be to have a configurable setting for the number of desired rows to show in multiweek view (this is what Google Calendar and Fantastical do; I suppose maybe iCal does that too, I don't know). Likewise for the amount of columns in week view. If issues #1 (closed) and #649 are implemented before this issue here, this part might be implemented already.

Potential to replace other traditional views

• This replaces the traditional "Month" view (when at least 4 week rows are shown, this is for all practical purposes a feature-complete replacement of the month view, functionally speaking). It could be renamed "Grid" view or "Multi-weeks" if desired. You could have both the "[Jump to] Today" action to align the current week to the top edge, and a "Align to current month" action (if necessary, but not sure that's actually necessary) to ratchet-align the 1st week of the current month to the top. Switching between months (with clickable UI buttons, or PgUp/PgDown keys) would simply scroll to ratchet-align the next/previous month's 1st week to the top.
• Eventually we could apply the same architectural concept to the week view, replacing the traditional "Week" view by something we could nickname the "Timetable" or "Multi-days" view: #649