Changing the compiler on Windows is not detected

**Describe the bug**
If a project is built with one compiler, and we switch to a different one with GHCup, the `'compiler'` file monitor will not be considered as changing because cabal does not check the version of the compiler, only checks:
```
-- from Distribution.Client.ProjectPlanning.configureCompiler
( hcFlavor
, hcPath
, hcPkg
, progsearchpath
, packageConfigProgramPaths
, packageConfigProgramPathExtra
)
```

On Linux, it is unclear how this triggers a rebuild, I suspect because the `hcPath` points to the real path and not the symlink. But on Windows the `ghc.exe` file is not changed, but instead the `ghc.shim` file next to it.

It would probably be enough if instead of `hcFlavor` we checked the `CompilerId` which is `CompilerId CompilerFlavor Version`.

**To Reproduce**
```
$ ghcup set ghc $VER1
$ cabal build all --dry-run
$ ghcup set ghc $VER2
$ cabal build all --dry-run -v3 | grep "File monitor 'compiler' unchanged."
```

**Expected behavior**
A change in compiler version should trigger a rebuild.

**System information**
- Windows
- `cabal` 3.14.1.1, any `ghc`

**Additional context**

Start at Distribution.Client.ProjectPlanning.configureCompiler and inspect how the 'compiler' file monitor is derived from compiler identity on Windows. Reproduce with two GHC versions selected through GHCup using the provided cabal build commands, then verify that changing the compiler version causes the monitor to invalidate and the dry run to rebuild; an open linked pull request already covers this issue.

Written by the indexing model from the issue text.