Make retrieving the subprocess asynchronous

[ehmicky]

Fixes #43.

Trying to keep the code small, although it's hard sometimes! :)

I've named the property .nodeChildProcess instead of .subprocess following your comment here: sindresorhus/execa#413 (comment). Also this would allow us to name the main return value subprocess instead of promise in the documentation, which might be easier to understand. Please let me know if this sounds good.

For example, we could document it along the following lines:

## nanoSpawn(...)

_Returns_: `Subprocess`

## subprocess

_Type_: `Promise<Result>`

### result.stdout

_Type_: `string`

## subprocess[Symbol.asyncIterator]()
## subprocess.stdout
## subprocess.stderr

_Type_: `AsyncIterable<string>`

## subprocess.nodeChildProcess

_Type_: `ChildProcess` (see Node.js doc)

[ehmicky]

If the subprocess throws during spawn(), we don't have access to the .stdout and .stderr stream properties. So the only way to know whether result.stdout/result.stderr should be undefined or not is to check whether spawnOptions.stdout is either "pipe" or "overlapped".

We could do that check, but to save some bytes, this PR is making result.stdout/result.stderr an empty string instead of undefined when using things like stdout: 'ignore' or stdout: 'inherit'. Also, this would make types simpler and smaller. Finally, it could be slightly simpler for users to assume those properties are always strings.

On the other hand, there are some benefits in the "undefined vs empty string" distinction that Execa is making with result.stdout. So I'm not sure whether that's a good idea or not. 🤔 Please let me know what you think.

[sindresorhus]

I think empty strings are the best choice here, and would be for execa too.

[ehmicky]

Fixed merge conflict.

[sindresorhus]

I've named the property .nodeChildProcess instead of .subprocess following your comment here

I agree. That's a better choice.