Better assignability errors to never-producing vacuous intersections

[DanielRosenwasser]

This was a naive first pass at something that I realized would be nice as I wrote up the breaking change section.

I couldn't do a fix everywhere because it became pretty impractical - for example, by the time we do the checks in some places, assignability, I guess we're given never instead of the original intersection.

const x1 = { a: 'foo', b: 42 };
const x2 = { a: 'foo', b: true };

declare let k: 'a' | 'b';

x1[k] = 42;

Things I'd like some guidance on:

1. Uh, I just hit 1 << 29 on NodeBuilderFlags. I've forgotten if that means I get a prize or a scolding for hitting the max unboxed value on a flag. (thanks @yuit)
2. Error message phrasing.

[weswigham]

You should probably search for and report the properties that conflict and their respective types, no? So the error is somewhat more actionable?

[DanielRosenwasser]

Definitely seems doable, but only if the approach in this PR seems reasonable.

[weswigham]

Seems OK. We could probably consider leaving behind more "breadcrumbs" like this in the future to explain how a specific type came about; but it's always about striking that balance between useful explaianation and terseness.

[sandersn]

Error seems good, and implementation seems OK except for the flags problem.

[sandersn]

why 'each' here? Wouldn't 'some' be correct?

If that's true, I'd just say "Types in that intersection ..."

[DanielRosenwasser]

Good point

[DanielRosenwasser]

#37618 provides the better error message.