Require opt-in to enable optimizations

[udoprog]

Checklist

• [*] Updated CHANGELOG.md describing pertinent changes.
• [*] Updated README.md with pertinent info (may not always apply).
• [*] Squash down commits to one or two logical commits which clearly describe the work you've done. If you don't, then Dodd will :).

This requires the user to explicitly enable optimizations through --optimize or by using the optimize option in Trunk.toml for potentially expensive optimizations to run.

This option is sorely needed, because optimizations might be enabled through static configuration in a <link data-wasm-opt="z"> statement in index.html, but you don't necessarily want that to run while working locally. So without another toggle you constantly have to edit your index.html file instead.

This is also a breaking change.

It might also be desirable to implicitly enable optimizations if --release is specified, but in that case I'd like to have a --no-optimize option as well, because I sometimes want to enable release builds while developing locally without optimizing as well. I'd prefer to add this separate to this PR though, because I haven't fully wrapped my head around the config module yet and how to best make multiple options interoperate.

[thedodd]

@udoprog optimizations are actually disabled by default (as of now), and even after #146 lands, optimizations can be disabled by setting data-wasm-opt="0" (https://trunkrs.dev/assets/#rust).

Long-term, I would say what we actually want to do is stand on the shoulders of giants and follow this pattern: https://rustwasm.github.io/wasm-pack/book/cargo-toml-configuration.html (profile based controls over optimizations and levels).

I would say that we should close this, as it is not needed.

[udoprog]

@udoprog optimizations are actually disabled by default (as of now), and even after #146 lands, optimizations can be disabled by setting data-wasm-opt="0" (https://trunkrs.dev/assets/#rust).

This is the editing being referred to. I've had instances where I've accidentally left data-wasm-opt="0" in the release build.

I'm glad you have a long term idea. But please consider accepting a shorter term fix initially that can be nuked once the long term is in place. This would significantly improve my experience working with trunk.

[thedodd]

@udoprog sorry about the very late response on my part. Your points here are definitely valid, and I like the path that you've mentioned about associating wasm-opt with --release profile, however providing a --no-opt option to disable wasm-opt even for --release mode would just be the same as disabling wasm-opt entirely, no?

Anyway, take a look at the discussion over here: #197