Just map type variables to constraints at certain positions for narrowing so that we do not map primitives

[weswigham]

Fixes #21360

getApparentTypeForLocation (which is how we enabled this, similarly to how we've made guards on this.foo.bar work when this.foo is an indexed access type) uses getAparrentType. That replaces primitives with their corresponding interfaces; I don't think we (ever) actually want do do that here (it just didn't matter when it was only ever used for the left hand side of a property access), so it's probably appropriate to factor out the constraint-mapping behaviors and perform only that here.

I've also renamed the associated functions as appropriate, since they no longer deal with apparent types.

[sandersn]

The fix looks good, but I’d like more work put in on clarifying the constraint concept to prevent future bugs.

[sandersn]

There is a thicket of related concepts here now that need better names: base constraint, syntactic constraint and this concept — constraint? — that I think is the correct one to use most of the time. But it doesn’t support index access types, for example.

Let’s talk in person and look over the current set of constraint-related functions. I don’t think we should be using the syntactic constraint much anymore, but I’m not sure of the best way to make that happen.

[weswigham]

TypeFlags.TypeVariable includes indexed accesses.

[weswigham]

After talking in person, I've since swapped just reusing mostof getBaseConstraintOfType, since that handles most of the behaviors we wanted anyway (including handling intersections correctly).

[sandersn]

I would inline this to avoid introducing a new name that differs by one (1) character from getBaseConstraintOfType.

Or put both of those functions right next to each other.