Add cache fallback with rolling timed expiration

[voxpelli]

This PR builds on #323 by @mmorel-35 but with two changes:

1. It adds a new cache-invalidate-after-days option that defaults to 120 days and which sets a rollable prefix between 0 and 9 to all of the cache keys, making it so that a cache key will change after 120 days. Can be set to 0 to deactivate. Reason for this is that npm will not remove data by itself: the cache will grow as new packages are installed.
2. Removes the fallback to a package manager independent cache key, only falling back to a cache from the same package manager.

This fixes #328 without creating an ever expanding cache size.

This also helps the cache be much more useful with a Dependabot / Renovatebot setup as a project that is dominated by PR:s from such sources will with the current cache setup in actions/setup-node pretty much only get cache misses and thus only ever set caches, rarely ever use them.

This adds a simple mechanism of falling back to a recent cache while avoiding the ever growing cache problem.

Feedback wanted:

• The rolling prefix might be a premature optimization on my part. Maybe one should just leave it out)

[voxpelli]

Will rebase

[nwalters512]

@voxpelli thanks for opening this! I think you'll need to run npm build/yarn build to update the files in dist/ for this to pass CI.

[voxpelli]

@nwalters512 Did so now, waiting for workflow runs to be approved again :)

[nwalters512]

@dmitry-shibanov any chance you could take a look at this PR? The introduction of fallback restore keys matches documented best practices and should allow the cache to be used in many more scenarios.

[voxpelli]

This has conflicts after #744 was merged, I'm on it

[voxpelli]

Ping @dsame, I adapted this to the changes made in #744, does it look like its in the spirit of what you did there?

[voxpelli]

Anything I can do to help out on getting this reviewed?