This action currently has a pretty conservative approach to caching in order to avoid ever-growing cache sizes that end up being slower than no cache at all. I think that makes sense as a default, but for projects with a lot of dependencies, a cache miss can be really painful. This PR adds a new option for a middle ground that uses more restoreKeys that are less specific like Github recommends in their docs, but periodically expires the cache which puts an upper bound on how long a cache can snowball for. I picked 1 month for the upper bound.

This periodic expiry is accomplished by adding the current year and month of the run to the cache key, so runs will first use a cache exactly for the current lockfile hash, and then only use a cache from the most recent month. There's no global cache that it falls back to in order to avoid unbounded cache size growth. That means the first run of the month will always rebuild the cache from scratch, but I think that's fine to have one slow build a month instead of one slow build every time you change any dependencies.

Thanks for your feedback!