Underlines in baselines should not consider nodes with .original set synthetic

[weswigham]

This is the churny bit of #58085, but the change itself is small.

This just changes our baselining requirements for the underlines to include any node with a .original pointer as not-synthetic. We already set this on most symbol name positions to the symbol's original declaration, even if we didn't copy exact position information (which we have good reason to not do at times, it turns out, and I'll have a followup related to - if those positions are from another file, we really shouldn't copy them, since it'll cause us to lookup gibberish for literal and identifier text (because we'll be looking in the wrong file for the span!)).

And while I'm here, let me head off the obvious question: yes, there's a scale of "how synthetic a node is", and there's a specific point on that scale we care about for these baselines. Any node not made in the parser gets NodeFlags.Synthesized set. That'll be every node the node builder produces - much too large a set. What we want to underline are nodes which have zero relationship to any input node. A node having a text range set is a strong relationship to an input span (ts.nodeIsSynthesized returns true if a node has no text range set), but isn't the only indicator, and may not always be set - a node having a .original set also indicates that it's related to an input node (and also might not always be set, though I'm struggling to see why you wouldn't set it and would only set the text span of a node, AFAIK the primary use of a .original pointer is to enable using checker APIs with the manufactured node).

[weswigham]

These are great example - these parameters all come from Array.prototype.every, which is declared in the lib (obviously), so while we can copy the parameter name nodes to create this signature node, we can't copy the position on the nodes, since that would try and pull gibberish text from this file, if it didn't crash for violating some invariant somewhere.