perf(compile): code cache

[dsherret]

Adds a lazily created code cache to deno compile by default.

The code cache is created on first run to a single file in the temp directory and is only written once. After it's been written, the code cache becomes read only on subsequent runs. Only the modules loaded during startup are cached (dynamic imports are not code cached).

The code cache can be disabled by compiling with --no-code-cache.

> hyperfine --warmup 2 scratch.exe scratch_new.exe
Benchmark 1: scratch.exe
  Time (mean ± σ):     282.9 ms ±   6.5 ms    [User: 78.1 ms, System: 15.6 ms]
  Range (min … max):   276.5 ms … 295.2 ms    10 runs

Benchmark 2: scratch_new.exe
  Time (mean ± σ):     129.7 ms ±   6.8 ms    [User: 17.1 ms, System: 9.7 ms]
  Range (min … max):   120.9 ms … 138.4 ms    21 runs

Summary
  scratch_new.exe ran
    2.18 ± 0.13 times faster than scratch.exe

Closes #26502

[felipecrs]

This is very promising. Have you thought of including the initial code cache inside the compiled executable as well?

[dsherret]

Yeah, maybe at a later time and as a separate option. The problem is it will make the binary much larger.

[felipecrs]

It all depends on the use case. For some use cases, improving the startup time on the second attempt onwards as opposed to in the first attempt in favor of a reduced binary size will make a lot of sense.

For other cases, it will not make any sense at all. For example: containers. There's only one startup attempt in that case.

[bartlomieju]

LGTM

[bartlomieju]

Unrelated to this PR, we should make this method be able to return sync or async response to save some ticks maybe.