Remove denort optimization

[ry]

denort is an optimization to "deno compile" to produce slightly smaller
output. It's a decent idea, but causes a lot of negative side-effects:

• Deno's link time is a source of constant agony both locally and in CI,
  denort doubles link time.
• The release process is a long and arduous undertaking with many manual
  steps. denort necessitates an additional manual zip + upload from M1
  apple computers.
• The "deno compile" interface is complicated with the "--lite" option.
  This is confusing for uses ("why wouldn't you want lite?").

The benefits of this feature do not outweigh the negatives. We must find
a different approach to optimizing "deno compile" output.

Fixes #10056

[nettybun]

why wouldn't you want lite?

Are you saying that lite will become the default for compile binaries? Or that instead all binaries will include unnecessary code like the formatter, linter, bundler, webgpu etc. I understand wanting to have less build complexity for sure but curious if there any size goals are for compiled binaries compared to the normal deno executable

[AaronO]

@ry Maybe a good tradeoff would be to only enable denort builds for main commits and releases, that would still speedup CI for PRs whilst having it CI'd in main and available for releases. (Not sure if there are many denort specific tests)

[AaronO]

But in general I agree that having faster CI is more beneficial to deno (improving iteration speed) than smaller binaries for deno compile

[nettybun]

Would it make sense to provide docs like "How to compile a minimal Deno yourself with less features"? Not sure if custom builds would be approachable to devs interested in smaller executables but without deep knowledge of Deno's workings - maybe it's as simple as commenting out components from the entry point file (likely not 😅) or maybe is Deno simply too tightly wired together to drop any features without panics...

[piscisaureus]

LGTM. @bartlomieju ok?

[bartlomieju]

LGTM