Is your feature request related to a problem? Please describe.
nyc 15 is moving away from spawn-wrap, will use process-on-spawn and node-preload in it's place. These two modules ensure nyc gets properly loaded into new processes, but they do not help with worker threads (note spawn-wrap also did nothing to help with worker threads). I'd like to add worker thread support to nyc.

Describe the solution you'd like
nyc needs to pass data to worker threads without requiring modifications to arguments of new Worker(...) run by the code being tested. An idea I have:

process.on('worker', options => {
	options.platformData('nyc', nycConfigClonableObject);
	options.nodeOptions.push('--require', require.resolve('./lib/wrap-thread.js'));
});

The above code assumes that new Worker() internally calculates options.nodeOptions based on the env.NODE_OPTIONS passed to it (see also #29117). This would allow nyc to inject preload modules if necessary without altering the process.env of the new thread.

Describe alternatives you've considered
Setting platform data during process startup could work for some use cases:

const threads = require('worker_threads');
threads.platformData('nyc', dataNeededToInitializeNYC);
threads.platformNodeOptions.push('--require', require.resolve('./wrap-thread.js')));

This would work for nyc but maybe another tool would need to calculate the object needed for platformData at the time of new Worker(). This is why my proposal is for 'worker spawn' hooks to ensure this is useful for more than just nyc. I'm also unsure how platformNodeOptions would be incorporated into the env.NODE_OPTIONS given to new Worker().

I considered patching the worker_threads core module. worker.SHARE_ENV is very problematic for this approach as it eliminates the possibility of using environmental variables to get nyc options into the worker threads. We would likely need to patch new Worker() to wrap worker data so that options.workerData = {userData: options.workerData, nycData}, then require('worker_threads').workerData would be patched to return the userData subproperty and we'd create a require('worker_threads').nycData export. This seems like it would be very messy, especially if any other tooling had a need to patch workerData in a similar way. I'm really not interested in this approach even if it could be forced to work.

CC @addaleax @arcanis @nodejs/tooling