Improve typing of assignments to properties of unresolved objects, v2

Improve typing of assignments to properties of unresolved objects, v2

Summary:
When type-checking an assignment of the form
```
$obj->prop = $val;
```
we type-check the left hand side, and in the case it has an unresolved type `(t1 | ... | tn)` we check that the type of `$val` is a subtype of each `ti`.  This is required for soundness because one way in which `$obj->prop` can have an unresolved type is when `$obj` itself has an unresolved type, e.g., `(C1 | ... | Cn)`, where `C1`, ..., `Cn` are classes having property named `prop` of types `t1`, ..., `tn` respectively.  However, this is not the only way in which `$obj->prop` can have an unresolved type.  Here is another example, which at the moment fails to type-check:
```
<?hh // strict
// Copyright 2004-present Facebook. All Rights Reserved.

class C<T> {
  public function __construct(public T $value) {}
}

function test(bool $b, int $x, float $y, num $z): void {
  if ($b) {
    $xory = $x;
  } else {
    $xory = $y;
  }
  $c = new C($xory);
  $c->value = $z;
}
```
Here `$c->value` has type `(int | float)`, but this type arises as an instantiation of a generic type of a single property, not as union of the types of different properties.  The above code should be valid but it is rejected by the type-checker.  One practical case in which this problem manifests itself is when we try to make `void` be the type of `null`, so that `?t` becomes equivalent to `t | void`.

This diff attempts to fix this problem.  It is a more principled fix than the one proposed in D8633124, and is more in line with the formal specification of assignment to properties (D8801786).  See inline comments below for a discussion of technical details.

Reviewed By: CatherineGasnier

Differential Revision: D8821525

fbshipit-source-id: be2c35a6916a1800e8138661c0e8bc2ab951eb51