Know when a process ended due to the `child_process.spawn()` `timeout` option

### What is the problem this feature will solve? When a process ends due to the `timeout` option of `child_process.spawn()`, there is no way to know whether that termination was due to the timeout. A `SIGTERM` is sent to the process, but that's pretty much it. ```js import {spawn} from 'node:child_process' const childProcess = spawn('node', ['-e', 'setTimeout(() => {}, 1e7)'], { timeout: 2e3, stdio: 'inherit', // no stdout/stderr }) childProcess.on('exit', (exitCode, signal) => { console.log({exitCode, signal}) // { exitCode: null, signal: 'SIGTERM' } }) ``` This makes debugging harder. Some users might be left wondering why the process ended if they don't pay attention to the `timeout` option. ### What is the feature you are proposing to solve the problem? Having a way to know whether the process ended due to the `timeout` option. Any implementation would work. Some potential ideas: - `timeout` event on `childProcess` - third boolean argument `timedOut` passed to the `exit` event - emit an `error` event with `error.code: 'ETIMEDOUT'` on `childProcess`. This is a breaking change since many users are currently listening for `error` events, so would probably not be a good idea. - `childProcess.timedOut = true` - `childProcess.timedOut()` returning a boolean ### What alternatives have you considered? One could possibly set a manual timeout like the following. ```js let timedOut = false setTimeout(() => { timedOut = true }, 2e3) ``` However, it defeats some of the convenience of the `timeout` option, since that one might as well call `childProcess.kill()` themselves then. Also, it is slightly unreliable since an unrelated `SIGTERM` could theoretically have been sent at the exact same time.