Value of SYSTEM_ROOT in windows varies in capitalization leading to cache misses between build servers and developers machines

### Description of the problem / feature request:

When you run bazel with --incompatible_strict_action_env enabled, differences in the SYSTEM_ROOT environmental variable cause cache misses. On my Windows 10 machine the generated path environmental variable is C:\WINDOWS, however on our 2019 server build machines, this either doesn't exist or is "C:\Windows"

### Feature requests: what underlying problem are you trying to solve with this feature?

Would like to have a normalized version of "C:\Windows" such that we get cache hits.

### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

On an existing project run using --imcompatible_strict_action_env:
set SYSTEM_ROOT=C:\WINDOWS
bazel build //...
set SYSTEM_ROOT=C:\Windows
bazel build //...
I expect to see 0 tasks run, and everything to be a local cache hit, however instead I get rebuilt tasks.

### What operating system are you running Bazel on?

Windows 2019 server + Windows 10.

### What's the output of `bazel info release`?

> Replace this line with your answer.

### If `bazel info release` returns "development version" or "(@non-git)", tell us how you built Bazel.

release 3.7.0

### What's the output of `git remote get-url origin ; git rev-parse master ; git rev-parse HEAD` ?

> NA its a release version

### Have you found anything relevant by searching the web?

Not much apart from original discussions on the feature.

### Any other information, logs, or outputs that you want to share?
Snippets from decoded--execution_log_binary_file

Build server
> environment_variables {
> name: "PATH"
> value: "C:\\Program Files\\Git\\bin;C:\\Program Files\\Git\\usr\\bin;C:\\Windows;C:\\Windows\\System32;C:\\Windows\\System32\\WindowsPowerShell\\v1.0"
>}

Developer machine:
>environment_variables {
> name: "PATH"
> value: "C:\\Program Files\\Git\\bin;C:\\Program Files\\Git\\usr\\bin;C:\\WINDOWS;C:\\WINDOWS\\System32;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0"
>}

Reproduce the issue on Windows with Bazel 3.7.0 using --incompatible_strict_action_env and the two SYSTEM_ROOT values shown, then compare the decoded execution_log_binary_file environment entries. Done means equivalent capitalization no longer causes rebuilds and the second bazel build reports local cache hits.

Written by the indexing model from the issue text.