Specify `shell` as `bash` in `Run tests and linters` step.

Fixes: Issue commitizen-tools#604

Switch `#!/bin/sh` to `#!/usr/bin/env sh` so scripts work on Windows as well as Linux and MacOS.

- Change shebang from `#!/bin/sh` to `#!/usr/bin/env sh`
- Set `$PREFIX` depending on OS

This should be used when parsing binary files, not text streams. The
regular expression fails on Windows because the stream contains `\n`,
but `os.linesep` is `\r\n`.

For reference, see https://stackoverflow.com/questions/38074811/what-is-os-linesep-for

Use `os.sep` for file paths. On Windows, this is `\`. On Linux and
MacOS, this is `/`.

Windows uses `\` for path separation, causing python to see the `\U` in
`C:\Users` as a Unicode string. Replace `\\` with `/` in file path
strings.

Also, the colon in drive paths on Windows causes the `partition` logic
in `bump.py` and `commands/bump.py` to fail. Perform the logic on the
path without the drive portion.

`argcomplete` does not support Git Bash on Windows out of the box. For
details, see https://kislyuk.github.io/argcomplete/#git-bash-support.

On Windows, `Popen` with `shell=True` reads the `COMSPEC` environment
variable to determine the shell to run, which defaults to Command
Prompt (see
https://docs.python.org/3/library/subprocess.html#subprocess.run).
For backwards-compatibility for older OS utility scripts, `COMSPEC`
should not be changed on Windows.

Command Prompt requires double-quotes instead of single-quotes. See

  - https://stackoverflow.com/questions/25534995/escape-double-quotes-in-git-config-from-cmd)
  - https://docs.python.org/3/library/subprocess.html#converting-an-argument-sequence-to-a-string-on-windows

Note that although the commitizen shell `scripts` shebangs have
been changed to a portable variety (i.e. `#!/usr/bin/env sh`),
which runs Git Bash on Windows when Git is installed (i.e.
the `sh.exe` executable that ships with Git for Windows),
`subprocess.Popen()` opens a child process from the active
running shell (i.e. via `CreateProcess()`). Hence, it will
still read `COMSPEC` and run a Command Prompt shell.

The Windows path separator is the backslash (i.e. `\\`). This causes
problems when python reads files from the `Users` folder since `\\U` is
the prefix for a Unicode string in python.

Since `os.path` can properly parse forward slashes on all OS's, we
substitute `\\` for `/` wherever `os.path` methods return backslashes.

For some reason, `pytest-mock` does not affect `os.isatty` when
`sys.stdin` is mocked to use `StringIO` (i.e. a file-like object).
Checking `sys.stdin.isatty()` works and is equivalent to checking
`os.isatty(0)` (`stdin` is file descriptor `0`).

For `pydocstyle`, use `--match-dir` switch to prevent traversal into
`venv/` folder.

For `commitizen`, use `cz` instead of `commitizen` as `cz` is present on
all OS's, but `commitizen` is not present in `venv/Scripts` on Windows.

Add error message if `test` script encounters unsupported OS.

`py -m` was added to command in `test_argcomplete_activation` during
experimentation and was forgotten to be removed.

Commit `d936262e` switched the `test` script to use `cz` instead of
`commitizen`, but forgot the prefix to the command is
`poetry run python -m`, which looks for a python module.

`cz` is not a module: it is an entry point script (specified in the
`pyproject.toml` table `[tool.poetry.scripts]`).

Switching `$PREFIX` to `venv/bin/` creates two problems:

  - The subdirectory `venv` creates differs depending on OS. On
    Linux/MacOS, the subdirectory containing copies/symlinks to
	Python binaries is `bin`, but on Windows it is `Scripts`.
	Similiarly, the `site-packages` directory on Linux/MacOS is
    `lib/pythonX.Y/site-packages`, but on Windows it is
	`Lib\site-packages`.
	See: https://docs.python.org/3/library/venv.html#module-venv

  - Since `commitizen` isn't the entry-point script, but rather
    `cz`, the command `venv/bin/commitizen` will fail on
	Linux/MacOS and Windows.

Poetry will check to see if it is currently running inside a
virtual environment, and if it is, it will use it directly
without creating a new one. If it isn't, it will use one that
it has already created or create a brand new one for you.

See: https://python-poetry.org/docs/managing-environments/

A better solution than switching the prefix would be to activate
the virtual environment. However, users can create virtual
environments with any name they choose (`venv/`, `.venv/`, or
otherwise). In addition, they can specify whether or not `poetry`
should create a virtual environment in the project folder
`virtualenvs.in-project`), or at all (`virtualenvs.create`).

Since switching to `venv/bin` only affects developers running
scripts locally (the GitHub Actions CI scripts run `poetry install`
and let it manage the virtual environment), it's best to
remove changing the `$PREFIX` and instead add instructions to
`README`/`CONTRIBUTING`/etc. to tell users to configure `poetry`
and activate their virtual environment appropriately if running
these scripts locally.

Command Prompt on Windows requires double-quotes. Otherwise, the
command

`${PREFIX}pydocstyle --convention=google --add-ignore=D1,D415 --match-dir="^(?![.]|venv).*"`

will fail with

'venv).*' is not recognized as an internal or external command

this will not affect the command in other Linux-based/bash shells.

Last CI run ended with a random `poetry` exception on Windows, which
happens from time-to-time.

Pipe appears broken in certain instances within the version of MinGW64
that ships as Git Bash in Git for Windows.

See:
  - https://sourceforge.net/p/mingw/bugs/2303/
  - msys2/MINGW-packages#13662