Improve build cache strategy

[yrodiere]

Ripped off from Quarkus

Here's how it will work:

1. We create a cache entry on push only. Pull requests only restore it.
2. We create a new cache entry every day, prefixed with something like
   2024-10-25.
3. When restoring the cache, we try the entry for the day first
   (2024-10-25) and default to the one for the month (2024-10-*).
   Critically, this means we will build each day's cache based on the
   previous day's cache.
4. Atlas infra uses its own, separate cache entries.

Opening as draft, because this is based on #9163, which must be merged first.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

[hibernate-github-bot]

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

[yrodiere]

Merging so we can see the effects in practice -- let's revert if someone disagrees.

[yrodiere]

@marko-bekhta @DavideD This might make sense on Search/Reactive too? Up to you, but I see that:

• Search almost uses up its cache limit, probably because using the POM hash in the cache key is very, very strict (add a space somewhere and you'll store another 1GB)
• Search doesn't cache the Maven install downloaded by Maven wrapper
• Reactive makes no use of the GitHub Actions cache at all.

If you apply something like what we have here, make sure that you apply #9166 too.

[yrodiere]

Also cc @gsmet -- thanks for the example!