Issue title: Windows arm corefx build failures
 Issue body: Windows arm corefx builds are failing with:
```
04:14:29   D:\j\workspace\arm_cross_che---99792267\_\fx\src\Native\build-native.cmd arm Release Windows_NT
04:14:29   **********************************************************************
04:14:29   ** Visual Studio 2017 Developer Command Prompt v15.7.6
04:14:29   ** Copyright (c) 2017 Microsoft Corporation
04:14:29   **********************************************************************
04:14:31   **********************************************************************
04:14:31   ** Visual Studio 2017 Developer Command Prompt v15.7.6
04:14:31   ** Copyright (c) 2017 Microsoft Corporation
04:14:31   **********************************************************************
04:14:32   [vcvarsall.bat] Environment initialized for: 'x86_arm'
04:14:32   Commencing build of native components
04:14:32   
04:14:35   CMake is a pre-requisite to build this repository but it was not found on the path. Please install CMake from http://www.cmake.org/download/ and ensure it is on your path.
04:14:35   Failed to generate native component build project!
```

e.g.:
https://ci.dot.net/job/dotnet_coreclr/job/master/job/jitstress/job/arm_cross_checked_windows_nt_corefx_baseline_bld/43/consoleFull

parent flow job: https://ci.dot.net/job/dotnet_coreclr/job/master/job/jitstress/job/arm_cross_checked_windows_nt_corefx_baseline_flow/

The build passes locally for me. I have cmake on my global path.

The failed job above was run on:
```
 Windows.10.Amd64.ClientRS4.DevEx.Open-1101034224124-0 (a0001BS)
```

Did the VMs change recently, esp. related to cmake installation?

@jashook @echesakovMSFT 
 Comments: 
 Comment 0: @weshaggard Any ideas on why our Windows arm corefx cross builds are failing?

It appears to be failing in src\Native\Windows\probe-win.ps1. I notice that the corefx version of this file doesn't have the change made in https://github.com/dotnet/coreclr/issues/8221.

Note that these builds run on the Windows.10.Amd64.ClientRS4.DevEx.Open Helix queue. I'm not sure what else uses this.

@MattGal Can you tell me what cmake(s) are installed on the Windows.10.Amd64.ClientRS4.DevEx.Open machines? Can I get access to one of these to try to repro the problem?



 Comment 1: @BruceForstall :  @ChulHul can probably answer that, I think it's whatever came with VS.  (Casey:  Can you comment about what specifically got installed on DevEx-VisualStudio_2017-15_7-Win10Ent-RS4-09-27-2018 ) ?   
Any artifact installed beyond what's on this VHD is listed inside https://dnceng.visualstudio.com/internal/_git/dotnet-helix-machines?path=%2Fdefinitions%2Fshared%2Fwindows.yaml&version=GBmaster

As for getting on a machine, please try to get a VM from the repro tool first then ping me if that doesn't work for you.
 Comment 2: Netfx3
Visual Studio 2017
java
office 365
cmake
adobereader
git
dotnet 4.6.2
dotnet 4.7
dotnet 4.7.1
dotnet 4.7.2
dotnet devpack 452
dotnet devpack 452
dotnet devpack 452
dotnet devpack 452
dotnet devpack 452
 Comment 3: cmake version should be 3.12.2
 Comment 4: I use the Helix Sender from a console app to send this command:

``` ps1
powershell -ExecutionPolicy Unrestricted  Write-Output 'CoreFX:'; iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/dotnet/corefx/master/src/Native/Windows/probe-win.ps1')); Write-Output 'CoreCLR:';  iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/dotnet/coreclr/master/src/pal/tools/probe-win.ps1'));
```

The output from a random `Windows.10.Amd64.ClientRS4.DevEx.Open` machine makes it pretty clear:

```
Executed on a0001HY
CoreFX:
CMake is a pre-requisite to build this repository but it was not found on the path. Please install CMake from http://www.cmake.org/download/ and ensure it is on your path.
exit /b 1
CoreCLR:
CMake is a pre-requisite to build this repository but it was not found on the path. Please install CMake from http://www.cmake.org/download/ and ensure it is on your path.
exit /b 1
```
 Comment 5: So, because I just can't leave well-enough alone, I did a few more experiments on these machines.

`where cmake` gave:
```
INFO: Could not find files for the given pattern(s).
```

`dir /s /b c:\cmake.exe` gave:

```
c:\Program Files\CMake\bin\cmake.exe
c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe
```

From this I can conclude:  
- VS 2017 is installed
- Standalone Cmake is installed
- Stuff's not on the path for ? reason

 Comment 6: I verified that simply calling "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat"  did not put CMake onto the path.
 Comment 7: OK I'm really done now as I'm late leaving.  THe Msi Exec property we need is just:
```
Property(C): ALLUSERS = 1
```
(Or @ChulHul  manually generated this, not sure)
 Comment 8: Those Powershell results are very odd because that script looks through the registry to figure out where CMake is installed, so maybe the registry wasn't set up properly during the install? Or the shell can't access it? Or, maybe it's getting confused because cmake is installed twice, or is in two different places, and the script isn't working in that case.
 Comment 9: Yup, I checked;  neither registry key is present.  I wonder if it's something related to SysPrep being run after it's installed. 
 Comment 10: I think you have a reasonable expectation of one form of CMake advertising to work, so I've filed the referenced issue above.  I'm uncertain how much work this will be because I don't know whose component would have stripped this out of both registry and path.
 Comment 11: What's odd, that needs to be investigated, is the following. In the failing job I referenced above (https://ci.dot.net/job/dotnet_coreclr/job/master/job/jitstress/job/arm_cross_checked_windows_nt_corefx_baseline_bld/43/consoleFull), we first build coreclr, which finds and uses cmake. Later, we clone and build corefx. Its managed build succeeds, but then its native build fails because it can't find cmake! So somehow the method that the coreclr build is using to find cmake maybe should be used to find cmake in the corefx native components build.
 Comment 12: Sounds like a good idea to do regardless as a fallback, but it'd be nice to not have sarafranco@example.net. 
 Comment 13: What's odd is it seems like coreclr finds cmake by either seeing an existing `CMakePath` environment variable, or by invoking `src\pal\tools\probe-win.ps1`, which you showed above gave an error (I presume there isn't a bug with your test code above, where the second download onto the same file name would give a download error, and we'd end up invoking the corefx `probe-win.ps1` script twice, or something like that)
 Comment 14: While I'm happy to have you keep investigating, if I could get access to a machine, I could investigate instead, or in addition.
 Comment 15: I was told by @maririos the repro tool was fixed, if not let me know and I'll do some machine shenanigans but it's non-trivial to do.
 Comment 16: I believe what is happening is the following.

- cmake is not on the path.
- We do a coreclr build first. It finds cmake just fine, by looking in the registry.
- We invoke a Python script to manage the corefx build and test run. My _guess_ is that the version of Python installed on these machines in an x86 (32-bit) version.
- We spawn a process to do the corefx build. This gets a 32-bit command prompt.
- We can't find cmake by looking in the registry because of the 32-bit "WoW" registry redirection: we only see the 32-bit registry, not the 64-bit registry. The version of cmake installed is a 64-bit version, which is only registered in the 64-bit registry.

The possible solutions:
1. Change the cmake install to put cmake on the global PATH.
2. Have the VM created by installing 64-bit Python, not 32-bit.
3. Change the cmake probe code to look "harder", such as looking in a specific path, for cmake.

@MattGal comments?
cc @echesakovMSFT 

 Comment 17: Fixed by https://github.com/dotnet/corefx/pull/33443
 Comment 18: Fix looks good, I'm not sure bitness matters as the original PS1s I read were already looking at the WOW paths though. 
{'source': 'GithubIssues', 'repo_name_with_owner': 'dotnet/coreclr', 'issue_id': 378076091, 'repo_stars': 14491.0}