feat!: use child_process when --no-threads is used

[sheremet-va]

Closes #1436
Closes #740
Closes #1544

This is a breaking change, because --no-threads no longer runs tests inside a worker (the name was misleading). After this PR is merged, disabling threads will force Vitest to use child_process API to run tests inside a different process. This might cause performance degradation, so there is a fallback to the previous behaviour.

To restore the previous behavior, use this configuration:

export default {
  test: {
    singleThread: true,
  }
}

Or run Vitest with --single-thread option:

vitest --single-thread

Note
Both --single-thread and --no-threads options group tests by environment and run only those tests in the same process/thread. Vitest can still run tests with several processes/threads if you use multiple environments.

[sheremet-va]

@AriPerkkio can you help me identify why coverage tests are failing for this PR? 🤔 (Something is up with source maps again)

[AriPerkkio]

This will also enable Vitest usage with aws-cdk testing: #1544 (comment)

[purepear]

Just thinking out loud here :) Instead of introducing singleThread, would it make sense to reuse threads by making it boolean | string? 🤔 (I'm probably missing something)

--threads // the default behaviour, same as "--threads true"
--threads false // use child_process, maybe same as "--threads 0"?
--threads 1 // same as setting minThreads:1 and maxThreads: 1, and it can work with any number "--threads 5"

[sheremet-va]

Just thinking out loud here :) Instead of introducing singleThread, would it make sense to reuse threads by making it boolean | string? 🤔 (I'm probably missing something)

--threads // the default behaviour, same as "--threads true"
--threads false // use child_process, maybe same as "--threads 0"?
--threads 1 // same as setting minThreads:1 and maxThreads: 1, and it can work with any number "--threads 5"

It requires other options to be set, when initiating Tinypool, not just max/min. I also don’t like having ambiguous option, new defaults are more explicit and don’t conflict with our other options.