[Feature Request] Replace entry script az.cmd with az.exe on Windows

[jiasli]

Is your feature request related to a problem? Please describe.

Currently on Windows, a cmd file is used as the entry point for Azure CLI: C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd

This causes several problems:

1. [Shell] Azure CLI receives corrupted arguments in PowerShell #15529. There was an attempt [Core] Add az.ps1 entry script for PowerShell #23514 to add az.ps1 for PowerShell, but that caused more issues and got reverted by [Core] Revert #23514: Rename entry script az.ps1 to azps.ps1 #24015

2. Pressing Ctrl+C can't terminate az commands immediately. Instead, Terminate batch job (Y/N)? is shown:
   

3. az.cmd can't be invoked by running az in WSL, Cygwin or Git Bash. The az Bash entry script introduced by [Packaging] Add az script for Git Bash/Cygwin on Windows #13197 caused more issues: Carriage return \r being appended to the output #13573

Describe the solution you'd like

Replace entry script az.cmd with az.exe on Windows.

Additional context

• The current az.cmd implementation requires Azure CLI to bundle a Python executable C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe. This Python interpreter is considered not secure by some restrictions and organizations, because it allows using build-in modules such as ctypes to execute arbitrary native code, bypassing enforcements such as Windows Defender Application Control (WDAC).

• We investigated using PyInstaller years ago in {Package} Use pyinstaller to package CLI #16115 but that PR didn't get merged.

• There is a similar feature request Ship azure-cli as binary instead as Python module #23397 focusing on packaging the whole Azure CLI as a standalone binary on all platforms including Linux, while this feature request only focuses on az.exe entry point on Windows and we may still have py files in the MSI package.

[yonzhan]

This is a good proposal we need to discuss with PM.

[bebound]

Adding entry_point in setup.py can create az.exe, which solves 1&2, but python.exe is still preserved.
PyInstaller seems to be the ultimate solution.

---

entry_point is not a valid option for Windows, because the generated exe file hardcodes the Python path.

In particular, relocating an environment isn't supported with entry-point scripts, which pip installs with a fully-qualified shebang. Moreover, entry-point scripts in Windows are created as exe files (e.g. "pip.exe") that embed the fully-qualified path of python[w].exe in the environment, plus a zipped main.py. For example, given an environment at "C:\Temp\env", running "C:\Temp\env\Scripts\pip.exe" in turn spawns a child process with the command line: "C:\Temp\env\Scripts\python.exe" "C:\Temp\env\Scripts\pip.exe". This breaks if the environment is renamed or relocated.

Ref: https://bugs.python.org/issue39469