Shell commands invoke /bin/sh directly

I am a maintainer of the [obelisk framework](https://github.com/obsidiansystems/obelisk). This week, I had to debug a very strange issue where some shell escaping was "working on my machine"™, but not my friend's. obelisk provides an integrated development environment that uses nix to ensure consistent behavior across platforms. In particular, we try to lock down which shell that is used when we invoke other executables.

However, we cannot ensure that our dependencies that use System.Process choose a shell in a way we can modify: In particular, ghcid uses `System.Process.shell`, and so on my machine, where `/bin/sh` is `bash`, and my friend's machine, where `/bin/sh` is `dash`, the behavior of shell escaping is different, and this causes `ghcid` to fail to invoke it's `--command` argument correctly.

My gut is that, just as one would reflexively invoke `#!/usr/bin/env bash` in a shell script that one wants to be portable, one would want `System.Process` to invoke `/usr/bin/env sh -c ` instead of `/bin/sh -c ` directly. Otherwise, the user cannot control the shell that is used at all without invasively modifying their entire system environment. A user may be surprised that the shell that they use to run their haskell program is not the same shell used to invoke shell commands from within the program, for example. I was surprised, at least!

This would be a rather significant change to the behavior of shell commands, so I'm not sure if that this change is desirable. At the least, a warning about portability would be appreciated.

Start by reading the implementation and documentation of System.Process.shell, focusing on how it selects /bin/sh and invokes commands. Reproduce the differing behavior with bash and dash, then review the issue discussion to determine whether the desired outcome is a configurable shell, a portability warning, or another documented behavior.

Written by the indexing model from the issue text.