Fix leaking file descriptors when subprocess creation fails

[tjstum]

If subprocess spawning fails (i.e. unsuccessful call to exec), the
created trio resources (i.e. the trio ends of the pipes that will be
used to send/receive data to the child) don't get cleaned up until the
next garbage collection run (which will call their __del__).

It would be nicer if this was deterministic, and that resources
created during the run of open_process were either completely
transferred to the Process object (which can take over the
management of them) or cleaned up (on failure).

To implement this, two ExitStacks are used: One will manage the
resources that need cleaned up unconditionally (the child ends of the
pipe); the other will manage the resources that need cleaned up on
failure.

Trio currently supports versions of python that lack
contextlib.AsyncExitStack. While there is a backport for 3.6
available on PyPI, the objects that represent the pipes (_FdHolder and
_HandleHolder) don't really need to have an async close. They are
internal implementation details anyway, so this refactors their
implementation to have the Stream/AsyncResource methods on the actual
Stream objects themselves. This allows us to use the regular ExitStack
and avoid an extra dep

[codecov]

Codecov Report

Merging #2193 (d03fd15) into master (7f44dcf) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #2193      +/-   ##
==========================================
+ Coverage   99.51%   99.55%   +0.04%     
==========================================
  Files         114      114              
  Lines       14759    14778      +19     
  Branches     2344     2344              
==========================================
+ Hits        14687    14712      +25     
+ Misses         47       44       -3     
+ Partials       25       22       -3     

Impacted Files	Coverage Δ
trio/_subprocess.py	96.88% <100.00%> (+0.02%)	⬆️
trio/_subprocess_platform/__init__.py	100.00% <100.00%> (ø)
trio/_unix_pipes.py	100.00% <100.00%> (ø)
trio/_windows_pipes.py	100.00% <100.00%> (ø)
trio/tests/test_subprocess.py	100.00% <100.00%> (ø)
trio/tests/test_ssl.py	99.58% <0.00%> (+0.55%)	⬆️
trio/_highlevel_ssl_helpers.py	100.00% <0.00%> (+11.76%)	⬆️

[tjstum]

/dev/fd certainly isn't guaranteed by POSIX, but it empirically seems to be common enough that it's fine to use in the tests like this.
There doesn't really seem to be an equivalent for Windows. psutil has a Process.open_files() that seems like it could be this, but on Windows, it really only gives you the paths to the files (and not something like an fd). That would also add an extra dep on psutil for the tests. I didn't see any straightforward way to enumerate all the Handles in a process either; there is a sysinternals program that does it, but it appears closed source, and we probably can't redistribute that binary in the tests (plus you'd have to shell out to it and interpret its output, which does not fill me with confidence).

So this is my best suggestion for testing this behavior. Happy to discuss alternatives!

[Fuyukai]

Realistically I don't see any issue with just using /dev/fds because I don't see any actual possibility for the closing behaviour to change on Windows.