Re-introduce caching for Windows CI

[cmb69]

This had been done when running on AppVeyor, but had been dropped when Windows CI was migrated to Github. While not terribly useful regarding the performance (maybe a minute can be saved), it still appears to be reasonable to avoid unnecessary requests to downloads.php.net.

To have the branch available in the action, we make detection of the target branch a separate step.

---

Note that this adds 140MB to the cache for each PHP version (currently only master), and each architecture (currently only x64). I don't think this is be a problem.

[TimWolla]

Somewhat related #14154: Will the cached values need regular updating or is a value that is cached once fine to keep forever?

Note that this adds 140MB to the cache for each PHP version (currently only master), and each architecture (currently only x64). I don't think this is be a problem.

We're already at the limit of 10 GB of cache storage. I wonder why we still have cache entries created from PRs after #14155 was resolved.

[cmb69]

Will the cached values need regular updating or is a value that is cached once fine to keep forever?

This caches php-sdk-2.3.0, which is unlikely to change often. It also caches the dependencies in the same cache (because the dependencies store some information in the php-sdk path); these will be update more often (especially for master), but I don't think that causes trouble; older caches will eventually be evicted. We can likely reduce the cache size by ~30MB, if we don't do a git clone of php-sdk-binary-tools, but instead a fetch a release; I would want to do that in a separate PR, because it's unrelated. Maybe we should wait with this PR until the other is done.

I wonder why we still have cache entries created from PRs after #14155 was resolved.

You are referring to refs/pull/*/merge, right? I think those would need special treatment (see https://stackoverflow.com/questions/63594658/git-refs-merge-vs-head-in-pull-request).