Test for returning Option<u128> and similar types returned in three registers by LLVM

[bjorn3]

LLVM will split this into three return registers, while Cranelift currently uses two return registers + implicit return value pointer: rust-lang/rustc_codegen_cranelift#1449

[Gankra]

Is it necessary to use the Real Option type or is this a classic "all things shaped like Option"?

If the latter, this can now be expressed as OptionU128.procgen.kdl:

tagged "OptionU128" {
  Some { _ "u128"; }
  None
}

(Literally just that, we procgen the functions from just a type definition now!)

Although that will implicitly get a #[repr(C)]. If you specifically want to test repr-rust:

@repr "rust"
tagged "OptionU128" {
  Some { _ "u128"; }
  None
}

If this is specific to the rust calling convention, we'll need to add that to CallingConventions and teach the rust backend how to support it (and the C backend to skip it).

[Gankra]

(Thinking out loud: strictly speaking we could actually say the repr of an non-@repr'd type matches the calling convention we're generating for, or that we will generate both repr variants... sigh more combinatorics and test keys and cli flags...)

[bjorn3]

Is it necessary to use the Real Option type or is this a classic "all things shaped like Option"?

Should be the latter.