GlobalStructInference: Un-nest struct.news in globals when that is helpful

[kripken]

If we have

(global $g (struct.new $S (i32.const 1) (struct.new $T ..) (ref.func $f) ))

then before this PR if we wanted to read the middle field we'd stop, as it is non-constant.
However, we can un-nest it, making it constant:

(global $g.unnested (struct.new $T ..)) (global $g (struct.new $S (i32.const 1) (global.get $g.unnested) (ref.func $f) ))

Now the field is a global.get of an immutable global, which is constant. Using this
technique we can handle anything in a struct field, constant or not. The cost of adding
a global is likely offset by the benefit of being able to refer to it directly, as that opens
up more opportunities later.

Concretely, this replaces the constant values we look for in GSI with a variant over
constants or expressions (we do still want to group constants, as multiple globals
with the same constant field can be treated as a whole). And we note cases where we
need to un-nest, and handle those at the end.

[tlively]

If you have this return a pointer, then you can avoid the need for a separate isConstant and you can use it conveniently in if (assignment) expressions.

[kripken]

Hmm, yeah, that might be a little less code here. But I'm not sure if it would be more clear (as working with pointers is less nice). Also, this is parallel to other existing APIs:

binaryen/src/ir/possible-constant.h

Lines 138 to 154 in 1079a9e

	bool isConstant() const {
	return !std::get_if<None>(&value) && !std::get_if<Many>(&value);
	}
	bool isConstantLiteral() const { return std::get_if<Literal>(&value); }
	bool isConstantGlobal() const { return std::get_if<Name>(&value); }
	bool isNull() const {
	return isConstantLiteral() && getConstantLiteral().isNull();
	}
	// Returns the single constant value.
	Literal getConstantLiteral() const {
	assert(isConstant());
	return std::get<Literal>(value);
	}

[tlively]

I see we have divergent styles here. All of the variant-using code I've written uses the pointer approach :)

[tlively]

Would it be worth mapping constants to Values to avoid this linear lookup?

[kripken]

I don't think so, since we have a limit on 2 values (so that we can do a single comparison to pick between them).

[tlively]

Ah, right, that makes sense, too.