feat: support runtime: 'bun_workers'

[AriPerkkio]

• Instead of using Node APIs like in feat: support Bun #70, use Bun's native Workers API

Benchmarking

$ bun isolate-benchmark.mjs 

> Options: { THREADS: 8, ROUNDS: 2000, IS_BUN: true } 
> 
> Tinypool { runtime: 'bun_workers' } | START
> Tinypool { runtime: 'bun_workers' } | END   12639 ms
> Cooling down for 2s
> .................... ✓
> 
> Native Bun workers | START
> Native Bun workers | END   9924 ms
> Cooling down for 2s
> .................... ✓

$ node isolate-benchmark.mjs 

> Options: { THREADS: 8, ROUNDS: 2000, IS_BUN: false } 
> 
> Tinypool { runtime: 'worker_threds' } | START
> Tinypool { runtime: 'worker_threds' } | END   10354 ms
> Cooling down for 2s
> ................... ✓
> 
> Tinypool { runtime: 'child_process' } | START
> Tinypool { runtime: 'child_process' } | END   13430 ms
> Cooling down for 2s
> ................... ✓
> 
> Native node:worker_threads | START
> Native node:worker_threads | END   9360 ms
> Cooling down for 2s
> ................... ✓

Bun still has issues when thousands of Workers are used: oven-sh/bun#5709. However I don't think Vitest users would run into this as we don't need to recycle workers in Bun - as long as ShadowRealm won't leak memory.

/Users/jarred/actions-runner/_work/WebKit/WebKit/Source/WTF/wtf/posix/ThreadingPOSIX.cpp(497) : size_t WTF::Thread::getRegisters(const ThreadSuspendLocker &, PlatformRegisters &)

TODO: Test with vitest-dev/vitest#4111