Improve types of result.stdout|stderr|all

[ehmicky]

Fixes #673.

Most of the time, we know that result.stdout|stderr|all is defined. However, we currently type it as possibly undefined. For example, the following fails becomes stdout is typed as string | undefined even though we know it cannot be undefined.

const { stdout } = await execa('echo')
console.log(stdout.trim())

The reverse is true: we sometimes know that result.stdout|stderr|all is undefined. Typing it as undefined instead of string | undefined would help TypeScript users realize they cannot use that property. For example, when using the buffer: false option or the stdout: 'inherit' option, users cannot retrieve result.stdout. The type should then be undefined, not string | undefined.

This PR implements this. The stream output is now correctly either undefined, string or Uint8Array.

This PR works with all the following cases:

• New result.stdio property
• stdio: string option
• stdio: array option
• stdio option with more than 3 items
• buffer: false option
• result.all property

Example from the type tests:

const { stdout, stderr, all, stdio } = await execa('unicorns', {stdio: ['pipe', 'ignore', 'pipe', 'pipe', new Uint8Array()]});
expectType<undefined>(stdout);
expectType<string>(stderr);
expectType<string | undefined>(all);
expectType<undefined>(stdio[0]);
expectType<undefined>(stdio[1]);
expectType<string>(stdio[2]);
expectType<string>(stdio[3]);
expectType<undefined>(stdio[4]);
// stdio[5] fails

[ehmicky]

stdio options which prevent Node.js from creating childProcess.std*, i.e. prevent us from retrieving the output.
Please note that when this does not apply when passing multiple values to this option. For example, result.stdout is undefined with { stdout: 'inherit' } but not with { stdout: ['pipe', 'inherit'] }. This PR accounts for this, and has a type test for it.

[ehmicky]

Due to how tuples are typed in TypeScript, we need to pass '1' not 1. That's because when mapping a tuple, the indices are iterated as strings, not numbers.