Investigate option unboxing logic to make it compatible with untagged variants.

[cristianoc]

          This difference means the compiler now unboxes the optional.

Well OK it makes assumptions about values of json type being stored unboxed (in the sense of optionals).
While correct in this case, I think it's incidental. And the option unboxing mechanism needs to be taught about untagged variants.
I will investigate in a separate issue. No need to worry about that here.

Originally posted by @cristianoc in #6218 (comment)

[cristianoc]

Here's a concrete example:

type isAlwaysObject = A(int)

@unboxed
type isNotAlwayObject = | @as(undefined) Undefined | B(int)

let canOptimizeOption = Some(A(10))
let cannotOptimizeOption = Some(Undefined)

And the outcome:

var canOptimizeOption = {
  TAG: "A",
  _0: 10
};

var cannotOptimizeOption = undefined;

The compiler's logic that optimises options needs to be taught about untagged variants.

[cristianoc]

More in general, the compiler should have certain capabilities. One of them is asking the question: does type t containundefined as a possible value? The answer being yes/no/undecided.
Similarly for other question such as: does type t contain only values of object type.