Bumps lower bounds for base, filepath, unix, and Win32. Drops support
for GHC < 8.6, as required by newer Win32.

Add Support for Windows Aarch64

Bump base bound to allow GHC 9.12

Co-authored-by: Cheng Shao <terrorjack@type.dance>

 Fix build with Javascript backend 

The new `CommunicationsHandle` abstraction requires the `setFdOptions`
from `unix`.

Fixes #327.

Correctly detect posix_spawn_file_actions_addchdir[_np]

It appears that CPP macro names are case sensitive, and the code was
previously checking for HAVE_posix_spawn_file_actions_addchdir
whereas Autoconf defines HAVE_POSIX_SPAWN_FILE_ACTIONS_ADDCHDIR. This
meant that calls to createProcess which set cwd to a Just value would
always fail to use posix_spawn and instead fall back on fork, which
is problematic when the parent process has a large residency.

Testing the fix revealed another issue, which is that _GNU_SOURCE must
be defined before any glibc headers are included, otherwise the _np
variant provided by glibc will not be declared.

More Windows subprocess mitigations

Prevent command-line injection for batch files with trailing char

This change ensure the regime implemented for HSEC-2024-0003 is
applied to batch file names ending with trailing chars that are
ignored by Windows.

Don't attach finalizers to Handles in CommunicationHandle API

We are now careful to not attach any Handle finalizers when creating
pipes for inter-process communication on Unix systems. Instead, the
handles are closed manually.

The finalizers were causing problems in situations such as the following:

  - the parent creates a new pipe, e.g. pipe2([7,8]),
  - the parent spawns a child process, and lets FD 8 be inherited by the child,
  - the parent closes FD 8 (as it should),
  - the parent opens FD 8 for some other purpose, e.g. for writing to a file,
  - the finalizer for the Handle wrapping FD 8 runs, closing FD 8, even though
    it is now in use for a completely different purpose.

This commit does not include a test, as the above bug is a bit difficult
to trigger.

This is useless at best, and a common source of confusion.

https://github.com/haskell/cabal/pull/10145
https://github.com/sol/hpack/issues/355

Fix CI on MacOS AArch64 runners

Add CommunicationHandle, an API for inter-process communication via Handles

Move tests to separate process-tests package & update CI to use GitHub actions

This commit adds the System.Process.CommunicationHandle module, which
provides the cross-platform CommunicationHandle abstraction which allows
Handles to be passed to child processes for inter-process communication.

A high-level API is provided by the function
`readCreateProcessWithExitCodeCommunicationHandle`, which can be
consulted for further details about how the functionality is meant to be
used.

To test this functionality, we created a new "cli-child" executable
component to the process-tests package. To work around Cabal bug #9854,
it was necessary to change the build-type of the package to `Custom`, in
order to make the "cli-child" executable visible when running the test-suite.
The custom Setup.hs script contains more details about the problem.

This commit moves the process testsuite to a separate package.
The rationale is that later commits require the test-suite to use a
Custom setup in order to work around Cabal bug #9854. This introduces a
setup-depends dependency on the Cabal library, and we would very much
like to avoid the dependency cycle:

  Cabal depends on process
  process depends on Cabal

Instead, splitting up the test-suite, we have:

  Cabal depends on process
  process-tests depends on process and on Cabal

To run the test-suite, you can use either of the following commands:

> cabal run process-tests:test
> stack test process-tests

There are a few other auxiliary changes, such as:

  - Using Cabal version >= 2.4 in the .cabal files,
    and fixing the associated warnings,
  - Using the CPP mingw32_HOST_OS define to check for Windows;
    this avoids having to define the same variable twice in two
    different packages.

Another aspect of the BatBadBut vulnerability that the previous patch
did not address is the fact that `%` cannot be easily escaped in a
double-quoted string. The vulnerability discussion suggests
transliterating `%` as `%%cd:~,%`, which should evaluate to an empty
string assuming that the `DelayedExpansion` registry setting is
disabled.

Here I have implemented this additional mitigation.

Sigh.