Inline nullable basic types without allocations

[Speedphoenix]

At the moment Null<Int> and Null<Float> used exclusively in one scope create unnecessary allocations on static platforms.

The compiler could inline those away like it does for anonymous structures:

var a: Null<Int> = 5;
var b: Null<Int> = null;
if (a != null)
	trace(a);

This is functionally the same as:

var a_null: Bool = false;
var a_val: Int = 5;
var b_null: Bool = true;
var b_val: Int;
if (!a_null)
	trace(a_val);

[Speedphoenix]

This is similar to #11332, but for nullables rather than parameter enums

[Simn]

@basro Do you think this is something we could add to the inline constructor code somewhat easily?

[basro]

I don't have much knowledge of what goes on with null on static targets so I don't have any idea of what would need to change.

@Simn could you get me a snapshot of the syntax tree before and after the inline constructor for a code sample that showcases the problem? I'd be able to reason about what is going on with that.
I'd prefer to avoid setting up the environment needed to compile haxe if possible.

[Simn]

Looking at this again, I wonder in which case this could even come up without being const-propagated away. If we statically know the null-ness and value of a local variable, then we likely end up optimizing it anyway. There could be artificial cases like this:

function main() {
	var a:Null<Int> = Math.random() > 0.5 ? 0 : 1;
	if (a != null) {
		trace(a);
	}
}

Here we don't know the value, but we do know the null-ness, which would allow us to optimize the branch away. However, this would require careful dataflow analysis in order to not break down immediately, e.g. on reassignment.

On balance, I don't know if this is worth the effort. Do we have a real-life example of some code which suffers from this and isn't already optimized properly with -D analyzer-optimize?