Improve handling of entries over midnight

[fnogatz]

@BeniRupp wrote in #39:

For further report functionallity (weeks, month, ...) we should re-think the data saved in the database. One idea is to split up a worklog when define the end of it in a way that we have one entry per day with the correct amount of time spent on this item. So we can query the data by the start date again:

So 2019-02-02 22:00:00 - 2019-02-03 06:00:00 is saved in the database as:

• 2019-02-02 22:00:00 - 2019-02-03 00:00:00
• 2019-02-03 00:00:00 - 2019-02-03 06:00:00

I prefer this generalised solution, too. Let's focus on this as soon as the full rewrite of #40 is merged.

[fnogatz]

I thought about this. Not really sure if this is really a good idea. What we want to achieve is:

• Easier filtering with overnight entries. Currently, the entries' keys are built based on their start time. Because a single entry might span a night, several days, or even weeks, we currently can not filter based just on the entry's key. This would be solved by having a single record for each day. This applies for all CLI commands that allow filtering, and in particular clocker report, which filters for all entries of the current day.
• Better display of overnight entries. Currently, clocker list provides the following output for overnight entries:

  1569182400  2019-09-22  [ 22:00:00 - 06:00:00 ]  (08:00:00)  [test1]
  

  It might be better to display it this way instead:

  1569182400  2019-09-22  [ 22:00:00 - …        ]  (02:00:00)  [test1]
  1569182400  2019-09-23  [        … - 06:00:00 ]  (06:00:00)  [test1]
  

  In clocker report for 2019-09-23, only the second line would be displayed.
  This could be solved by separate, connected database entries per day, though the data storage and display could be simply handled independently.

What still bothers me, is the following:

1. It creates a lot of overhead just to handle overnight entries. A straight-forward implementation idea would be to simply remove the end entry of an overnight database entry and provide a next instead; similarly omitting the start in favor of a prev for a continuing overnight entry. But this would basically require a rewrite of all application logic: clocker start, clocker end, clocker set all have to check if the current entry is or was an overnight entry, clocker report, clocker data, clocker list have to consider the prev and next entries.
2. The filtering problem is not solved. Since the prev and next entries are created only after having called clocker start, clocker end, or clocker set, starting a new entry just before midnight and calling clocker report right after would return no results. As a consequence, the previously mentioned logic had to be added even to otherwise just accessing commands like clocker report, clocker data, and clocker list. But even then it would not be clear which entries one has to look at, as clocker allows to run several entries concurrently. (While writing this, I had the idea to just encode whether an entry is still running or not in its key, like open-1569182400 or closed-1569182400, which would allow fast filtering again. However, this leads to the next point...)

The consequence of the second point is that even with overnight entries, we need to filter all currently stored entries to find the ones that would create a new database entry for the current day. So maybe we are just over-engineering here? My own clocker instance has more than 16'000 entries which can be filtered in under 500ms. We could just naively loop through all entries for better filtering, and simply change the method to display overnight entries to our needs.

RFC!