Refactor summaries computation to allow for different time intervals

[muety]

Currently, summaries are persisted on a per-day level. Moreover, the summary calculation logic assumes that there are no overlaps.

For performance reasons, it would be cool to have support for storing summaries on different levels of granularity, e.g. have daily summaries alongside monthly or yearly summaries.

Then, for when a request comes in, there are three options how we could make Retrieve() behave:

• Option A: Make it as smart as to "adaptively" choose from the available summaries while (a) avoiding overlaps and (b) minimize minimizing the number of individual summaries used
• Option B: Hard-code what "granularity levels" could theoretically exist, then start with the largest one that still matches the requested interval, probe to find according persisted summaries and otherwise continue with the next smaller one
• Option C: Explicitly store the "granularity" level with a summary (e.g. have an interval column with values daily, weekly, etc., similar to what we have for leaderboard_items) and then follow the logic from option B of choosing the appropriate granularity level given the requested interval

I think option C is easiest to implement. However, this needs to be planned out further.

[muety]

Also, allow to persist filtered summaries (see below) to speed up a bunch of different queries.

wakapi/services/summary.go

Line 101 in e21d9b2

// Filtered summaries are not persisted currently