Repository: node
Issue: Stop throwing for unsupported options in `Worker`'s `execArgv` and `env.NODE_OPTIONS`.
Labels: worker

### Version

v17.2.0

### Platform

_No response_

### Subsystem

worker_threads

### What steps will reproduce the bug?

Consider this `test.js` file:
```js
const { isMainThread, Worker } = require("worker_threads");

if (isMainThread) {
  new Worker(__filename, {
    // execArgv: process.execArgv
  });
} else {
  console.log("Hello from the worker!", process.execArgv);
}
```

> NOTE: `--experimental-json-modules` and `--title` are just examples

Run these two commands:
```
node --experimental-json-modules test.js
node --experimental-json-modules --title foo test.js
```
They will log
```
Hello from the worker! [ '--experimental-json-modules' ]
Hello from the worker! [ '--experimental-json-modules', '--title', 'foo' ]
```

Now, uncomment the `execArgv: process.execArgv` line and run the two commands again. The first command will still log
```
Hello from the worker! [ '--experimental-json-modules' ]
```
however, the second one throws:
```
Error [ERR_WORKER_INVALID_EXEC_ARGV]: Initiated Worker with invalid execArgv flags: --title
    at new NodeError (node:internal/errors:371:5)
    at new Worker (node:internal/worker:191:13)
    at Object.<anonymous> (/home/nicolo/Documenti/dev/babel/babel/test.js:4:3)
    at Module._compile (node:internal/modules/cjs/loader:1097:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1149:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47 {
  code: 'ERR_WORKER_INVALID_EXEC_ARGV'
}
```

This mans that _the default behavior of the Worker `execArgv` option is not to inherit `execArgv` from the parent thread_ (contrary to what the documentation says).

**Why would you want to explicitly pass `execArgv: process.execArgv` anyway?**

A few days ago I was trying to implement a require hook that internally uses a `Worker`, and in order to avoid registering it recursively in an infinite worker-spawn loop I tried to filter out the `--require` flag:
```js
new Worker(workerFile, {
  execArgv: process.execArgv.filter((val, i, argv) => val === "--requrie" || argv[i-1] === "--requrie"),
});
```
this seemed to work, until it crashed in a test that was using the `--expose_gc` option.

Today, I found the exact same problem in `jest-worker` (a Jest subpackage that is often also used outside of Jest): https://github.com/facebook/jest/pull/12103 was opened because `jest-worker` didn't work when running Node.js with `--max_old_space_size`.

Since Node.js doesn't provide the list of flags supported by workers progrmmatically (and I didn't find it in the docs either :sweat_smile:) there is no way to filter the `execArgv` used by a worker.

**What is the current behavior?**

I initially expected the real default behavior to be something like `execArgv: process.execArgv.filter(isSupportedByWorker)`, but it looks like it's not either. Consider for example the `--expose_gc` (which is disallowed in workers) option with this example:
```js
const { isMainThread, Worker } = require("worker_threads");

if (isMainThread) {
  new Worker(__filename);
} else {
  console.log("Hello from the worker!", process.execArgv, globalThis.gc);
}
```

If you run `node --expose_gc test.js`, it will log
```
Hello from the worker! [ '--expose_gc' ] [Function: gc]
```

You can see that the `gc` function is present. This means that the disallowed flags are _not_ ignored (and not even "ignored but still used to populate the `process.execArgv` array): they are used and affect the runtime behavior.

### How often does it reproduce? Is there a required condition?

Only for the options marked as "unsupported" in workers.

### What is the expected behavior?

I see four possible solutions:
- Just ignore the unsupported options
- Never throw, but warn when passing an unsupported option to a worker (potentially even if it's passed by default without an explicit `execArgv`).
- Only throw if the unsupported option is not also used as an `execArgv` of the parent thread.
- Always throw for unsupported options (so that `execArgv: process.execArgv` becomes the default behavior), and provide a `Worker.filterExecArgv` utility that removes disallowed options, and that I would have used like
  ```js
  Worker.filterExecArgv(process.execArgv).filter((val, i, argv) => val === "--requrie" || argv[i-1] === "--requrie")
  ```

If the current behavior is expected, then the docs should be updated to mention that the default value cannot be replicated by explicitly passing an `execArgv` option.

### What do you see instead?

_No response_

### Additional information

_No response_