Make the life time of preparedIds configurable #174
Description
At the moment, the life time of a preparedId is only implicitly defined: the preparedCount configuration option in the run.properties files controls the number of preparedId being kept. If the current number exceeds that setting, the oldest ones are discarded in the Tidier.
It might be desirable to be able control the life time more directly, configuring a maximum age. It might be desirable to control that from both perspectives: to set a minimum life time that a preparedId should have at least, but also to make sure that the preparedId should not be valid for ever. To keep things simple, we would probably content ourselves with one single setting such as preparedIdLifetimeSeconds, though.
We will probably still keep preparedCount as a fall back setting, to avoid the number of ids to grow beyond any bound. But then, it would be assumed that it is set large enough that the actual number of retained ids will be smaller in practice at least most of the time. We would log a warning if we need to resort to deleting ids that have not reached their configured life time.
We could even consider to add some maxAge parameter to the prepareData API call to allow the user to request a custom maximal life time. It should be clearly documented that this is without commitment and we would not allow it to exceed the default setting. But there might be legitimate use cases where a shorter life time is desired by the user.