Initializer the union selector of undefined upsilon nodes

[Keno]

While we're guaranteed never to look at undefined values,
we're not guaranteed that the type information can't change, which
in the case of a union generates code to change the layout.
As a result, we need to make sure to have the union selectors
be valid (the actual data will be junk and no semantic operation
will ever look at it, but it shouldn't be ouf of bounds).

Fixes #29152, #29066.

[vtjnash]

As a result, we need to make sure to have the union selectors be valid

How are we defining "be valid"? Are we confident that we'll detect throw the undef-ref exception before we reach any attempt to assign the value / update it through a pi-node / box or unbox it? I just want to check, since those may emit a call to trap if they notice that the selector (runtime) is OOB from the target type (compile-time).

[Keno]

No, I'm not entirely convinced that you can't run into this situation other ways (PiNodes in particular). I think the most likely situation in which it'll happen is if the first union element gets dropped by the PiNode on a path where that union element can't usually be active. We may have to add a maybeUndef flag to PiNodes (or allow the MaybeUndef type to propagate through to codegen) and in that case disable the assert in the fall through path.

[Keno]

The other alternative of course is to have an explicit tindex to mean undef and handle it that way. We do have that information, so we could pass it through to codegen.

[Keno]

I'll mention again in this context the idea to have singleton Undef type which would be an error to use in rval position and gets constructed only as the initial value of all variables.

[vtjnash]

Yeah, that's what I was worried might be able to happen also—and I'm not sure if that would be limited to PhiC either. We could also entirely stop emitting trap in this case and just use an llvm::Undef value. I like trying to emit trap, since it's nice to try to catch our mistakes early, but maybe that's simply not a correct model for our JuliaIR semantics.

[nalimilan]

Bump. This apparently fixes the crash reported at #29066 (and probably also #29996).

[Keno]

I've rebased this. Talking to @vtjnash, we should merge this and then continue addressing the remaining unfixed issues after.