Add `--trim`-mode (compile-time) preference

[topolarity]

Although it's quite nasty (since it splits your pkgimage cache if it gets used), JuliaC.jl should automatically set a Base._trim_enabled preference so that we can customize packages as needed for --trim deployment, e.g.:

const trim_enabled = Preferences.load_preference(Base, "_trim_enabled")
function type_unstable_function()
    if trim_enabled
        # unnecessary type-unstable things ...
    end
end

The challenging part of this design (beyond setting up a correctly merged / modified LocalPreferences.toml) is figuring out where to attach the Preference.

Preferences.jl does not have a method to attach these to any Base / "Julia" namespace, but we also do not want to inject a dummy package just for the purpose of attaching a preference. Maybe a not-too-terrible hack is to attach it to Preferences.jl itself, as in:

[Preferences]
_trim_enabled = true

julia> using Preferences
julia> load_preference(Preferences, "_trim_enabled")
true

Anyone who tries to load the preference is guaranteed to have access to Preferences.jl, so they'll at least be able to refer to this "global" preference.

[topolarity]

This is required to implement what @maleadt suggested in SciML/LinearSolve.jl#778 (comment)

[topolarity]

@gbaraldi suggested we provide a function in Base that can be overlaid / invalidated - that does have the advantage of not splitting the full pkgimage cache, but it is limited to modifying run-time code.

In particular, it cannot affect how any top-level / precompilation code executes, including macros, etc.

[KristofferC]

Couldn't a path forward be to add something like load_preference(Base, "trim_enabled") to Preferences.jl where there is no preference TOML file backing that preference but it is set by e.g. the startup options of julia? Basically, you would specialize the lookup rules for preferences for the Base module.

I am personally not a fan of the redefining a function plan because there isn't a good way to cache the result of that, or?