Add endpoint to get play stats

[robbevp]

This PR adds an extra endpoint: /plays/stats through which a user is able to get their aggregated play stats.

this endpoint should be enough for most use cases we have for plays. It can replace the calculations to show the simple overall play count, and simplify many calculations for the recently played albums, artists or the stats page.

These stats can be filtered by album or artist (for smaller requests) or the played_at date (for detailed stats)

TODO:

• Create some real life tests with a high volume of plays
• Maybe add the total played length of a track?

Update about real life tests

I did some tests in my development env to verify whether this approach can scale.
This test db contains:

• ± 45k tracks (though only a small portion contain an actual audio file)
• ±60k plays
  This seemed to be no problem - most pages with stats are returned between 200 and 350ms. I don't really expect requests to take considerably longer when there are more plays

[robbevp]

@chvp I had to tmp comment this line, since it was causing problems.
When the line was included our query also tried to order per id, which was not present in the GROUP BY clause. (Even if the request didn't use any scopes). Do we still use/need this somewhere?

ERROR:  column "plays.id" must appear in the GROUP BY clause or be used in an aggregate function at character 188
STATEMENT:  SELECT COUNT(*), MAX(played_at) as last_played_at, "plays"."track_id", "plays"."user_id" FROM "plays" WHERE "plays"."user_id" = $1 GROUP BY "plays"."track_id", "plays"."user_id" ORDER BY "plays"."id" DESC, "plays"."track_id" DESC LIMIT $2 OFFSET $3

[chvp]

Clients implicitly rely on sorting by id to handle the edge case where new data appears while syncing. It needs at least some ordering, otherwise the database might decide to start ordering differently, leaving the clients with some missed data (even if some data disappears). The reverse by id is the order where there is the least chance for older data to disappear.