`ExampleTests`, `ProcessPipelineTests`, and `SpawningSubprocessTests`
still fail seemingly spuriously. But at least the ones that already pass
we can enable

Pull request: #275

Pull request: #279

Pull request: #280

…with std streams redirections (#283)

Fixes #282

Unlike usage of `System.in`/`System.out`/`System.err` programmatically,
or the `scala.Console` equivalents, output from subprocesses with
`os.Inherit` is not affected by `System.setIn`/`setOut`/`setErr`. This
is often counterintuitive, because you expect redirecting these streams
to redirect all output, only to find output from subprocess leaking
through a side channel to the original process `in`/`out`/`err`.

This PR adds the `os.Inherit.in`/`out`/`err` dynamic variables, which
can be used to re-assign `os.Inherit` on a scoped threadlocal basis.
This allows developers who use `System.setOut` or `Console.withOut` to
also redirect subprocess output within the scope of the stdout redirect,
without users working within those scopes to have to remember to
redirect them manually at every callsite.

Because we do not control `System.setOut` or `Console.withOut`, there
isn't really a way for us to detect and do this automatically (e.g.
redirects may happen even before OS-Lib has been even classloaded) and
so we have to rely on it being opt-in.

As an escape hatch, in case users do not want this behavior, we provide
a `os.Inherit0` redirect which performs identically to the original
`os.Inherit` even in the process of redirecting
`os.Inherit.{in,out,err}`

Covered by an added unit test

Pull request: #285

They aren't important enough to be top-level folders, since they really
belong to the test suite

Fixes #284.

The idea is to introduce a new flag to both `os.proc.call` and
`os.ProcGroup.call`, as well as backing implementations in
`os.ProcessLike`. The flag, `timeoutGracePeriod`, allows for a
configurable use of `SIGKILL`, which forcibly kills a process, after the
issue of a `SIGTERM`, which allows a process to clean up. The values for
the flag have the following behaviours:

|value | behaviour|
|------|-----------|
| -1 | When `timeout != -1`, only a `SIGTERM` will be issued, requiring
the child process to gracefully terminate. |
| 0 | When `timeout != -1`, only a `SIGKILL` is issued, demanding the
child terminate immediately with no chance of graceful cleanup. |
| n > 0 | `timeout != -1`, first issue a `SIGTERM` and then wait for a
further `n` milliseconds before issuing a `SIGKILL`, this provides a
reasonable timeframe for process cleanup, but accounts for misbehaving
processes. |

For now, the default has been set to `timeoutGracePeriod = 1000`.

Pull request: #288

Pull request: #290

…#292)

Now these can be spelled `os.call()` and `os.spawn()`, and we provide
`Shellable[TupleN]` conversions to make it convenient to call without
constructing a `Seq(...)` every time. So this:

```scala
os.proc("ls", "doesnt-exist").call(cwd = wd, check = false, stderr = os.Pipe)
```

Becomes

```scala
os.call(cmd = ("ls", "doesnt-exist"), cwd = wd, check = false, stderr = os.Pipe)
```

The original purpose of the `os.proc().call()` style was to avoid the
verbosity of constructing a `Seq` each time, and by making it flexible
enough to take tuples, this mitigates that issue without the annoying
method chaining style.

The new style still isn't actually shorter in terms of number of
characters, but it is a lot cleaner in terms of "function call taking
named/optional arguments" rather than "fluent call chain with first call
taking varargs and second call taking named/optional parameters". It
also aligns with the Python `subprocess.*` functions which OS-Lib in
general is inspired by

To support Scala 2, the `Shellable[TupleN]` conversions are defined
using codegen. Scala 3 allows a nicer generic-tuple implementation, but
we'll be supporting Scala 2 for the foreseeable future.

The older `os.proc.*` APIs remain, both for backwards compatibility, as
well as to support the `pipeTo` API used to construct process pipelines

Duplicated some of the existing subprocess tests to exercise the new
APIs. Did not duplicate all of them, as the new APIs are pretty dumb
forwarders to the existing ones so we don't need to exercise every flag
in detail.

Updated the docs to point towards the new APIs, but with a mention that
the older `os.proc().call()` style is still supported