tokio_util::run and tokio::run_on_current_thread should accept Future<Output=()> instead of Future<Output=Result<(), ()>>. Currently, all the passed futures have to add Ok(()) or futures::future::ok(()) unnecessarily to call this method.

This PR removes tokio_util::block_on - refactored compiler and file 
fetcher slightly so that we can safely block there - that's because 
only blocking path consist of only synchronous operations.

Additionally I removed excessive use of tokio_util::panic_on_error 
and tokio_util::run_in_task and moved both functions to cli/worker.rs, 
to tests module.

Closes #2960

After landing #3358 the benchmarks exploded indicating problems with workers and deno_core_http_bench.

This PR dramatically fixes thread/syscall count that showed up on benchmarks. Thread count is not back to previous levels but difference went from hundreds/thousands to about ~50.

- Bundles are fully standalone. They now include the shared loader with
  `deno_typescript`.
- Refactor of the loader in `deno_typescript` to perform module
  instantiation in a more
- Change of behaviour when an output file is not specified on the CLI.
  Previously a default name was determined and the bundle written to that
  file, now the bundle will be sent to `stdout`.
- Refactors in the TypeScript compiler to be able to support the concept
  of a request type.  This provides a cleaner abstraction and makes it
  easier to support things like single module transpiles to the userland.
- Remove a "dangerous" circular dependency between `os.ts` and `deno.ts`,
  and define `pid` and `noColor` in a better way.
- Don't bind early to `console` in `repl.ts`.
- Add an integration test for generating a bundle.

* Split ThreadSafeState into State and GlobalState. State is a "local"
  state belonging to "Worker" while "GlobalState" is state shared by
  whole program.
* Update "Worker" and ops to use "GlobalState" where applicable
* Move and refactor "WorkerChannels" resource

Use --lock-write=lock.json or --lock-check=lock.json on the command
line.

towards #2960

This ensures the deno executable is properly created before running the integration tests.

Also allows deno_cli to be used as a lib. Docs are now properly generated: https://docs.rs/deno_cli/0.18.4/deno_cli/

Towards #2933
Prep for #2955

* remove fetch_source_file_and_maybe_compile_async and 
  replace it with State.fetch_compiled_module

* remove SourceFile.js_source()

* introduce CompiledModule which is basically the same as
  deno::SourceInfo and represents arbitrary file that has been 
  compiled to JS module

* introduce //cli/compilers module containing all compilers

* introduce JsCompiler which is a no-op compiler
  - output is the same as input, no compilation takes place
  - it is used for MediaType::JavaScript and MediaType::Unknown

* introduce JsonCompiler that wraps JSON in default export

* support JS-to-JS compilation using checkJs

* merge SourceFileFetcher trait and FileFetcher struct

* move logic related to source file fetching to //cli/file_fetcher.rs

* use Result when creating new ThreadSafeState

* rename `ModuleMetaData` to `SourceFile` and remove TS specific
  functionality

* add `TsCompiler` struct encapsulating processing of TypeScript files

* move `SourceMapGetter` trait implementation to `//cli/compiler.rs`

* add low-level `DiskCache` API for general purpose caches and use it in
  `DenoDir` and `TsCompiler` for filesystem access

* don't use hash-like filenames for compiled modules, instead use
  metadata file for storing compilation hash

* add `SourceFileCache` for in-process caching of loaded files for fast
  subsequent access

* define `SourceFileFetcher` trait encapsulating loading of local and
  remote files and implement it for `DenoDir`

* define `use_cache` and `no_fetch` flags on `DenoDir` instead of using
  in fetch methods

This is in preperation for dynamic import (#1789), which is more easily
implemented when errors are dynamic.

The rules are now as follows:

* In `import` statements, as mandated by the WHATWG specification,
  the import specifier is always treated as a URL.
  If it is a relative URL, it must start with either / or ./ or ../

* A script name passed to deno as a command line argument may be either
  an absolute URL or a local path.
  - If the name starts with a valid URI scheme followed by a colon, e.g.
    'http:', 'https:', 'file:', 'foo+bar:', it always interpreted as a
    URL (even if Deno doesn't support the indicated protocol).
  - Otherwise, the script name is interpreted as a local path. The local
    path may be relative, and operating system semantics determine how
    it is resolved. Prefixing a relative path with ./ is not required.

A lot of its functionality is unused still, but the goal it to slowly
migrate logging functionality to it. There is also a useful progress bar
which can be ported over later - it depends on this module.

https://github.com/rust-lang/cargo/blob/4c1fa54d10f58d69ac9ff55be68e1b1c25ecb816/src/cargo/util/progress.rs

Adds ModuleSpecifier, which wraps a URL. This is now passed around instead of
specifier and resolver strings.

* Compiler no longer has its own Tokio runtime. Compiler handles one
  message and then exits.

* Uses the simpler ts.CompilerHost interface instead of
  ts.LanguageServiceHost.

* avoids recompiling the same module by introducing a hacky but simple
  `hashset<string>` that stores the module names that have been already
  compiled.

* Removes the CompilerConfig op.

* Removes a lot of the mocking stuff in compiler.ts like `this._ts`. It
  is not useful as we don't even have tests.

* Turns off checkJs because it causes fmt_test to die with OOM.