• Make sure you've installed the latest version using instructions in the wiki

Output from azd version
Run azd version and copy and paste the output here: azd version 1.7.0 (commit 49d6adc)

Describe the bug
When defining scripts, we currently use yaml like this:

hooks:
  predeploy:
    windows:
      shell: pwsh
      run: Export-ModuleMember -Variable API_URL && npm run build
    posix:
      shell: sh
      run: export API_URL && npm run build

This separate the commands to run into two categories: execution for posix-systems (Linux/Mac), and Windows.

The issue is that the distinction is not clear at all, and even misleading:

• If I'm on Windows and using WSL, which version will run?
• If I'm on Windows and using Git Bash, which version will run?
• sh will actually run bash and not sh, which is misleading (bash has a different feature set and by default is not POSIX-compliant)
• If I'm on Windows without Powershell install, how can I use the default cmd.exe? (for simpler commands)
• If I'm on Mac or Linux but with Powershell installed, which version will run?

These issues could be cleared by using a simpler script definition based on the shell name, similar to how it works in GitHub Actions:

hooks:
  predeploy:
    pwsh:
      run: Export-ModuleMember -Variable API_URL && npm run build
    bash:
      run: export API_URL && npm run build

Instead of discriminating the system (which makes no sense when using WSL or Git Bash), we could just specify which shell to use. The logic could be:

1. Try to run the first specified shell in the list (in this example, pwsh). Test could be simply running <shell> --version and see if it fails.
2. If the shell is available run the script, otherwise continue testing with the next shell option.

You could even make the shell specification optional, and use whatever default shell is available on the system for simple commands, for example:

hooks:
  predeploy:
    run: npm run build

It would even be possible to support the new syntax and keep the old deprecated syntax for backward compatibility with existing azure.yaml configurations.

What do you think about this proposal?