Feat: Delete old cache keys

When the a new cache key is written and then it should be possible to delete older caches for the same branch.

Example:

PR:
Commit 1:

• No cache on input: Ideally reads cache from main branch by stripping the ref and whatever else off.
• Executes other steps: Success
• Writes cache -<ref=1>-...
  Commit 2:
• Reads cache -<ref=1>-...
• Executes other steps: Success
• Writes cache -<ref=2>-...
• NEW: Deletes cache -<ref=1>-...
  Commit 3:
• Reads cache -<ref=2>-...
• Executes other steps: Failure
• Not writing cache
• Not deleting any cache
  Commit 4:
• Reads cache -<ref=2>-...
• Executes other steps: Failure
• Writes cache -<ref=4>-...
• NEW: Deletes cache -<ref=1>-...

Some people may employ different strategies here. But the majority of users employ strategies involving branches and or refs for their cache keys thereby explicitly preventing cross PR/branch caching. Thus older caches are no longer needed and can be deleted immediately after successfully writing a new cache. If people are too aggressively adding commits there is of course a danger that deletion would now be triggered while the next commit's action has not yet finished reading the older cache. Those could be handled by configuring that at most the last caches stay up.

The goal here is to automatically keep cache usage as low as possible to prevent cache overuse which would trigger automatic cache eviction which may delete caches one still wants.

The issue does not name files, tests, or entry points. Start by tracing how cache keys are written and how branch or ref keys are selected; define completion around deleting older caches only after a successful write, preserving caches after failures, and supporting a configurable number of recent caches.