cgen: make possible to initialize sumtype with default type (first variant)

[felipensp]

Fix #22030

[spytheman]

You will have to change vfmt too, so that it would not sort the variants anymore.

[StunxFS]

And what happens if the first variant of the sumtype is a struct that has some field that is of pointer type? (the compiler should force explicit initialization)

[felipensp]

And what happens if the first variant of the sumtype is a struct that has some field that is of pointer type? (the compiler should force explicit initialization)

In this case it is zero'd initilization, just like {0} was doing before.

[spytheman]

Excellent work.

[spytheman]

@felipensp about @StunxFS's comment, consider this:

struct Node {
    parent &Node
    left &Node
    right &Node
}
type Sumtype = Node | int

// n := Node{} /* will produce a compiler error, because the reference fields will be nil pointers */

s := Sumtype{} // currently, the compiler does not care, even though the node that will be created by default will be the same as `n` above
dump(s)

producing (without any compiler messages):

#0 02:36:52 ^ fix_sumtype_init /v/oo>v run ss.v
[ss.v:11] s: Sumtype(Node{
    parent: &nil
    left: &nil
    right: &nil
})

[spytheman]

i.e. the compiler currently acts on s := Sumtype{}, as if I had written:

struct Node {
    parent &Node = unsafe { nil }
    left &Node = unsafe { nil }
    right &Node = unsafe { nil }
}

It is a second order effect. This PR already makes sure, that s itself will be valid, while it was not before (the unknown sumtype value would break matches etc). The default value in the sumtype value though, is something that the compiler normally prevents, but without additional checks, will be a source of puzzling bugs, for people that depend that their struct instances with references are always properly initialized.