cli: Add required --experimental flag for experimental features (e.g. --trim)

[topolarity]

The intention here is to clearly signal when a feature is "not yet fully implemented" vs. "feature-complete and in pre-release" vs. "fully released and ready for production use"

The only feature gated behind this right now is --trim. Trim has its core functionality implemented (and folks seem to be enjoying it!) but the deployment / linking story in particular is still in its very early stages, esp. because our existing techniques for, e.g., pre-loading libunwind, libstdc++, etc. no longer work in a shared library context.

Once --trim is ready for a broader chunk of the ecosystem / language, we can peel off the --experimental flag

[topolarity]

I still slightly favor renaming --trim to --experimental-trim - I think folks are likely to set --experimental and forget

But either way is good with me. Might be worth input from triage.

[StefanKarpinski]

I don't think we need to be that cautious. People may set and forget --experimental but they did have to set it. It also has the advantage of being forwards compatible: if you have something that's working and it stops being experimental then you don't have to change your scripts once that thing stops being experimental. You can remove the experimental flag but you don't need to.

[oscardssmith]

Triage likes --experimental="trim,other_experimental_option" --trim since this way experimental arguments are explicitly opted into, but it doesn't break scripts for experimental CLI arguments to "graduate" to non-experimental status.

[tecosaur]

If experimental becomes a string-flag like that, could it be nice to also have an envvar like JULIA_EXPERIMENTAL_FEATURES="trim,some_other_feature" that serves as the default value when --experimental is not explicitly passed?

[StefanKarpinski]

I'm happy with this PR the way it is. Having to pass the names of individual experimental features feels too fiddly to me. There's basically only one question: is this command future-proof or not? If you've passed --experimental then it's possible that it will break; if you haven't passed --experimental then it should work.

[StefanKarpinski]

LGTM.

[topolarity]

Maybe a middle-of-the-road solution would be to have more coarse-grained --experimental categories? Something like:

--experimental="cli-options,language-feature-x"

I think it's safe to group all of the experimental CLI features together, but for experimental language features (which I think @Keno has speculated about maybe introducing) it's probably worth having a specific opt-in.

[biona001]

I have no idea how to pass this flag.

$ ./julia contrib/juliac.jl --output-exe hello hello.jl --trim
ERROR: julia: --trim is an experimental feature, you must enable it with --experimental

$ ./julia contrib/juliac.jl --output-exe hello hello.jl --trim --experimental
Unexpected argument `--experimental`

$ ./julia contrib/juliac.jl --experimental --output-exe hello hello.jl --trim
Unexpected argument `--experimental`

???

(I built Julia from master just now)

[topolarity]

That's due to #56602 - I'll try to make some "executive" decisions and push that along today