Basically this does pre-processing of TypeScript files and gathers all the
dependencies asynchronously. Only then after all the dependencies are gathered,
does it do a compile, which at that point all the dependencies are cached in
memory in the compiler, so with the exception of the hard coded assets, there
are no ops during the compilation.

Because op_fetch_source_files is now handled asynchronously in the runtime, we
can eliminate the tokio_util::block_on() which was causing the increase in
threads. Benchmarking on my machine has shown about a 5% improvement in speed
when dealing with compiling TypeScript. Still a long way to go, but an
improvement.

In theory the module name resolution and the fetching of the source files could
be broken out as two different ops. This would prevent situations of sending the
full source file all the time when actually the module is the same module
referenced by multiple modules, but that could be done subsequently to this.

* migrate deno_typescript crate to Isolate.register_op API
* remove dual-dispatch mechanism
* update Isolate tests to new dispatch mechanism

This adds a new op to get a single env var.

Co-authored-by: NBartek Iwańczuk <biwanczuk@gmail.com>

Previously: dial("tcp", "deno.land:80")
Now: dial({ hostname: "deno.land", port: 80, transport: "tcp" })
Similarly with listen().

When the global timer fires earlier than expected, which apparently
happens sometimes on server editions of Windows, we didn't call any
setTimeout callbacks, but we *also* didn't reschedule the global timer
to fire again later.

When this situation occurred it would make deno exit abruptly if there
were no other asynchronous ops running on the event loop. It could also
lead to application hangs if the upcoming setTimeout callback was
critical for the application to make progress.

Fixes #2933

The yarn.lock file is moved from //third_party to the root of
the main repository. This is where other package metadata
files (e.g. Cargo.lock and package.json) are also located.