Support for cron-style cache definitions

### Description

I was wondering if support for defining cache update cycles in a CRON-like format would be a potential feature. It offers more flexibility than the current system, where you can only define how often a widget should be updated, but not exactly when. This might be a use case not many people have, but I personally could use that.

For example, I build a custom-api widget to fetch content from a REST API once a day. Sadly, the provider doesn't always update exactly on midnight, but sometime in the early morning hours. Setting the cache duration to 24h would sometimes lead to an error message if the API didn't respond with the full content. I also don't want to set the timer to something lower, like 8h or 6h, because that would fetch unnecessarily often. Ideally, I would like to define it as `cache: "0 7 * * *"`, so that it fetches the content once at 7 each morning, so that I can check the content out when having breakfast.

The contributing guidelines note to avoid introducing new dependencies, which would be needed here. Go-Libraries to parse cron-style timers exist. Obviously, a functionally minimized parser could be natively implemented into Glance to avoid using a dependency, but using a pre-existing library seems like the better way in terms of functionality.

I have added this in a local copy of the repository using https://github.com/robfig/cron. The implementation effort is quite low, adding a new cacheType, the parsing function and some extra logic in the getNextUpdateTime. I've added it as a new field, `cache-cron`, which could be used in a widget definition, but combining it into the existing `cache` field should also be possible, just needs one more step to decide which format was specified.

So, it is certainly possible, and not that much work, to add. I have not made a pull request due to the previously mentioned addition of new dependencies, and because my implementation is probably not the best. I would appreciate it if something like this would be officially added. Otherwise, I would just maintain my own private fork, which isn't too big of a deal.

Start by tracing the existing cacheType handling and getNextUpdateTime logic, then review how widget cache definitions are parsed. Decide whether cron syntax belongs in the existing cache field or a new cache-cron field, and verify that scheduled updates occur at the requested time without breaking current cache durations.

Written by the indexing model from the issue text.