Statistics should be based on slices based on the file timestamps

Currently the statistics work by storing one measurement each time the StatisticsStep is run. This has a couple of drawback.

1. We might have holes in the staticstics, for the periodes of time where the integrity service hasn't been running.
2. A speciale case is the scenario, where a collection has been established sometime before the statistics workflow was enabled on the collection. Here we might have a long history of files stored in the file timestamp which we could use to deduce the development of the collection size.

A improvement would therefore be to define a statistics interval, which the statistics step will use to determine how many measurements it should store when run.

Example 1: A year old collection (earliest file creation timestamp 365 days old), gets updated to now have a enabled integrity statistics service. The improved statistics with a configured statistics interval of 1 day, would then calculate the collection size for each day and store these as individual measurements in the statistics DB.
Example 2: The integrity workflow is very expensive so we only run it once every week. We would on the other hand like to we the change in the collection size in a daily resolution. This is not possible with the current solution.
Example 3: The integrity service has not been run for a month because of scalablity problems. When the integrity service is started again we would like to have all the missing statistics points created, as the necessary data is available as file creation timestamps.