Optionally use *nix line endings for Windows scripts

When running command line programs on Windows, the temporary script that gets created is forced to use Windows-style line endings. I'd like that behaviour to be configurable: it's a very sensible default, but it causes problems when using non-default shells that expect *nix style line endings.

For context, I maintain a number of Cygwin packages, and I'd like to be able to use the GitHub runner infrastructure to build those. That requires using Cygwin Bash, which doesn't support CRLF line endings in scripts. I'd like to be able to specify Cygwin's Bash as the shell to run commands in, but currently that fails.

Currently, I'm using commands like this (slightly contrived but working example):

run: |
  C:\tools\cygwin\bin\bash.exe -c 'cygport moreutils.cygport build'
  C:\tools\cygwin\bin\bash.exe -c 'cygport moreutils.cygport compile'
  C:\tools\cygwin\bin\bash.exe -c 'cygport moreutils.cygport test'

I'd like to be able to do things like this instead:

run: |
  cygport moreutils.cygport build
  cygport moreutils.cygport compile
  cygport moreutils.cygport test
shell: bash

Currently that works, apart from the line ending issue – the final argument gets a \r attached to it, which causes the command to not be recognised.

The behaviour here is triggered by ScriptHandler.cs line 241. I imagine the new behaviour would work like the current behaviour by default, but with a new optional eol parameter that can appear everywhere the current shell parameter can (e.g. defaults.run.eol and jobs.<job_id>.steps[*].eol). That parameter would accept arguments of crlf or lf (and perhaps more esoteric options) to force particular line ending behaviour.

Start with src/Runner.Worker/Handlers/ScriptHandler.cs around line 241, where Windows script line endings are forced. Trace how shell settings are parsed and propagated, including defaults.run and step options. Done means Cygwin Bash can use LF endings while the existing CRLF behavior remains the default.