Add compiler flags to override specific const values

Rationale: there are situations where certain aspects (eg. features, presets, etc) shall be customized at compile-time.
Common scenarios are eg. system/distro specific pathes, disable features. And for various reasons (eg. reduced footprint
on constrained/embedded systems, reduced possible attack surfaces, ...) the dead code of disabled features shall be eliminated.

Why existing methods aren't sufficient ?

1. Linker option -X:

We already can tell the linker to override initial values for variables (but not constants).
Obviously, those can't help with dead code elimination, since the compiler can't know which actual value it will have.
OTOH, with constants, the compiler can do that, eg. that code

if (FeatureFooEnabled) {
    doSomething()
} else {
   doOther()
}

can be easily reduced either one of the branches (depending on whether FeatureFooEnabled is true or false).
Similarily on any const expression (eg. Foo > 12, or backend == "boo", ...).

Thus, we can just inject some preset values, forcing some possible code pathes to be practically dead, but those can't be eliminated yet. On large/complex projects, those practically dead code can make up large portion of the final binary
(e.g. measured in docker/containerd: systemd support and its long chain of dependency contributes about 20%)

2. Conditional compile by tags

This is the currently only practical option for (compile-time) optional features. Sufficient in small projects, but can easily become insane to maintain in large projects w/ lots of dependencies, e.g.:

• for each switch needs two extra files
• only boolean -- choices of n > 2 options (usually) need to exploded to n * 2 files
• can only work on values that can be transformed to bools (eg. not list of names/strings)

But there's more:

Build tags are global for the whole build, thus affect all dependencies as well - there's no scoping yet.
Therefore, tag naming must be done very carefully - one tag could have different meaning in different packages.
And when certain features depend on others, it can easily become tricky picking the right combinations.

3. Code generation

As long as the affected code is only in main module itself, it's not hard to write a little generator for creating some little .go files defining some consts. But this won't help for within dependencies. Even if those also implement their own generators one by one, we'd still need a common protocol for naming / passing along the individual settings.

Proposed solution:

Add a compiler flag similar to the existing -X linker flag (also fully qualified names), but here affecting consts instead:

1. Compiler has an list (actually map) of overrides (name & value pairs) - untyped literals
2. Whenever an const is resolved to its value, it consults the overrides list and take value from there, if exists
3. The original type is always retained - the compiler converts the literals to the original type
4. If conversion impossible, emit an type mismatch error (build should certainly break here)
5. If some values had been replaced, at least one code elimination phase is necessary (if it wouldn't come after, anyways)

Practical use examples:

package johndoe
const EnableFoo = true
...
func doWhatever() {
    ...
    if EnableFoo {
        doSomeComplicatedStuff()
        useMoreDeps()
    }
   ...

Compiling with: go build -Djohndoe.EnableFoo=false ...
will result in the const EnableFoo changed to false and the big branch in doWhatever() will be eliminated
entirely - as well as everything else that isn't called anymore.

Impact:

Everything (IMHO) can be implemented just inside the compiler (possibly in build tool, some bits for passing through the args), right at the point after the AST had been built and validated, right before dead code elimination starts. Some extra care needs to be taken for checking type compatibility, but that shouldn't be a big deal since const can only be scalars anyways.

No language change necessary, no risk for incompatibilities.