Fix compiler crash when evaluating null-conditional assignment to splattable value-type

[aharabada]

This PR fixes a crash during code-gen when using a splattable struct in a null-conditional assignment.
The crash can be reproduced with this code:

class Foo
{
	private StringView mStr;

	public StringView Str
	{
		get => mStr;
		set => this?.mStr = value; // <- this line causes the crash
	}
}

class Program
{
	public static int Main(String[] args)
	{
		Foo f = scope Foo();
		f.Str = "ABC";

		return 0;
	}
}

In debug builds of the IDE, this produced the following error message:

Fatal Error in Module: Testy_Foo
Function: ?set__Str@Foo@Testy@bf@@QEAAXUStringView@System@3@@Z
DbgLoc: @10 _bf.Testy.Foo.set__Str:Program.bf:48:10
BfIRCmd_Store Match Failure:
Val: i8* %value_mPtr
Ptr: corlib.StringView@System@bf* %0 in ...\IDEHelper\Backend\BeIRCodeGen.cpp:318

The problem is that if the value that is assigned through the null-conditional is splattable, a splat might be passed to BfModule::FlushNullConditional. In there, result = LoadValue(result); returns the splat-head unchanged, which causes a type mismatch in the store operation that is created later: the type of the target will be a pointer to the entire struct (in this case StringView*) while the source pointer will just be the splat-head (in this case i8*). CreateAlignedStore doesn't check the types, but the backend does, which then crashes.

The fix is to use LoadOrAggregateValue instead of LoadValue. If necessary, this will aggregate the splat, so we use the correct value and thus type for the store operation.

[bfiete]

A bug report and ALSO a fix at the same time? I love it!