[turbopack] Add bundling support for worker_threads (#87746)
Add support for bundling worker_threads workers
Previously we only supported tracing dependencies of worker threads. However, this could trigger issues if the callsite was getting bundled since we would believe that the file was both bundled and unbundled.
The solution is to support bundling modules using worker threads and implementing the threads. This requires a new reference and loader module type which follows the patter of async-loaders and webworkers.
An interesting consideration is about file extensions. `new Worker(...)` takes a relative or absolute filepath, in node 23+ that means you can load typescript files directly, so we support the same. If you want to load a `.ts` file you need to write `foo.ts` we don't do any pattern rewriting.
This fixes a bug reported by an X user: https://x.com/strugglercss/status/2002504736860484008?s=20. The problem with the previous approach is that we would record the reference as 'traced', but if you did `new Worker(__filename,...)` then we would end up with 'traced references' to a file that was bundled. This caused issues during tracing when we tried to add CachedExternalModule references to the nft json files
```
Error [TurbopackInternalError]: NftJsonAsset: cannot handle filepath url
Debug info:
- Execution of get_all_written_entrypoints_with_issues_operation failed
- Execution of EntrypointsOperation::new failed
- Execution of all_entrypoints_write_to_disk_operation failed
- Execution of Project::emit_all_output_assets failed
- Execution of emit_assets failed
- Execution of emit failed
- Execution of <NftJsonAsset as Asset>::content failed
- NftJsonAsset: cannot handle filepath url
at <unknown> (TurbopackInternalError: NftJsonAsset: cannot handle filepath url) {
```
there `url` was due to a `require('url')` statement in a bundled file this caused us to produce an external shim, but a `new Worker(__filename)` caused us to also create a traced reference to the same file. The problem there was simply that the `ident()` for a `CachedExternalModule` contains a dummy filepath that broke the nft.json asset production. The root issue here is that the `FilePathModuleReference` was using the wrong `AssetContext` to construct the referenced module which lead to the wrong files being traced. After investigation @mischnic and I determined that that was an insufficient fix since we really do need to rewrite the reference. Proper bundling support fixes this directly and the pattern here paves the way for more worker support in the future.
This doesn't seem like the only way a synthetic module (like an extern module) might end up as a dependency of traced module, so a more robust solution is probably in order.
