Add bash script ability to Windows binary

### What feature do you want to see added?

I'd love the ability to run bash scripts on Windows via the binary wrapper. I *think* it would "just" be adding the cookie name/value, script, and shell flags as alternative, mutually exclusive flags (i.e. either the cookie name/val, and script flag or the executable and args flags would be valid in the required set). And then to adjust the `launcher` function to further switch what is run based on the passed arguments.

---
We write our Jenkinsfiles to run on both Linux and Windows using bash (with `git-for-windows/git` providing bash in the `$PATH`). We tried to use the binary wrapper via `-Dorg.jenkinsci.plugins.durabletask.BourneShellScript.USE_BINARY_WRAPPER=true` to improve reliability. Unfortunately, this forces it to apply to all `sh` scripts, regardless of the worker OS. Because the durable task binary wrapper for Windows only supports `cmd` and `powershell` specifically, it fails to run anything, and we end up with the following error:

```console
process apparently never started in C:\[...]\jenkins\workspace\[job]\build@tmp\durable-2c062c95
```

I wasn't able to rerun with `BourneShellScript.LAUNCH_DIAGNOSTICS=true`, but my assumption based on the code here and in `jenkinsci/durable-task-plugin` is that it would show a `flag provided but not defined` error via the `flag.Parse()`.

---
(See the Jenkinsfile [here](https://github.com/docker-library/meta-scripts/blob/205031aee2fdfbbd449038afd58f0f0a6915c217/Jenkinsfile.build))

### Upstream changes

As far as I know, I don't think this needs any changes in `jenkinsci/durable-task-plugin`.

If this isn't a feature that you want to support, then I'd recommend a change to `jenkinsci/durable-task-plugin` that limits the binary wrapper on Windows to only CMD and Powershell and just runs bash without the wrapper even when `BourneShellScript.USE_BINARY_WRAPPER=true`.

### Are you interested in contributing this feature?

Yeah, I'd like to implement this; I'm fairly familiar with go code. I would like to do it in multiple stages. Rather than just copying code from the `bash` folder to the `windows` folder, I was hoping to re-unify them into one go package and take advantage of `_unix.go` and `_windows.go` and `//go:build` directives for the OS-specific differences. And once they are unified (can be done in a fully separate PR), then add the extra flags to the Windows implementation. Does that sound reasonable? I'm happy to share work in progress changes if you'd like to discuss something more concrete.

Start by comparing the Go implementations in the bash and windows folders, especially the launcher function and existing _unix.go/_windows.go build-tag structure. Trace how flag.Parse() defines the Windows wrapper arguments, then determine the separate bash script and executable paths. Done means the Windows binary can run bash scripts while preserving CMD and PowerShell behavior, with the relevant wrapper checks passing.

Written by the indexing model from the issue text.