Inconsistent handling of Intersection of Objects when destructuring

Possible dup of #5843 with simplified example and workaround.

([Try](https://flow.org/try/#0C4TwDgpgBAYg9nACgJzmAzlAvFA3gKCigDMEAuKAOwFcBbAIwmXwF999RIoAhAQ2RRpMOAkXr8KNBk1btRUAMZxK6YHijjkAGigA6faThQWFPgNQYoAMlgJBlkSXJQAjDs0UXxgNyEoACkMKeCQLdABKbygAemjYAEEASQAZWXx5JRU1XA1+HX1dQ2NguzDrHn57YXUg13cJVx8-QOcQqsiYuMR4gGUetPlYqAB1AHkAJQBpePHRgFUAOQARP0zVdU18gwQTdQKAEgBRAA9eBWAAHjMqgD4t3SPT84u2sJvjbBrnN1zkTyaiC04CVQkJIs0PFQ6IxkOCWEA))

```js
type FooProps = {
foo: number
}

type BarProps = {
bar: number
}

{
const { bar, ...foo }: BarProps & FooProps = { foo: 1, bar: 1 };
(foo: FooProps); // FAIL
}

{
const { bar, ...foo }: FooProps & BarProps = { foo: 1, bar: 1 };
(foo: FooProps); // PASS
}

{
// WORKAROUND
const { bar, ...foo}: { ...$Exact, ...$Exact } = { foo: 1, bar: 1 };
(foo: FooProps);
(bar: number);
}
```

Flow produces the following error on the line marked `FAIL`. There is no reason for the order of an intersection to affect the outcome.

The workaround does the same as an intersection would do, but appears to avoid the mistake the flow makes in the intersection syntax.

In my original use case, `foo` and `bar` were optionals, and I thought it was that the intersection was turning them into required props, but this demonstrates that there is something else going on related to the ordering of the intersected types.

```text
11: (foo: FooProps)
^ Cannot cast `foo` to `FooProps` because property `foo` is missing in `foo` [1] but exists in `FooProps` [2].
References:
10: const { bar, ...foo }: BarProps & FooProps = { foo: 1, bar: 1 };
^ [1]
11: (foo: FooProps)
^ [2]
```

NB: You may also find `$Shape` useful in place of `$Exact`, especially if the object type that you are trying to reference is already an intersection. In this case, $Exact appears to copy over whatever inconsistency is created by the intersection, whereas `$Shape` does not. At time of writing `$Shape` is not documented.