parser and language service fixes for unclosed element tags

[atscott]

fix(compiler): always match close tag to the nearest open element

This commit updates the parser logic to continue to try to match an end
tag to an unclosed open tag on the stack. Previously, it would only
push an error to the list and stop looking at unclosed elements.

For example, the invalid HTML of <li><div></li>, has an unclosed
element stack of [li, div] when it encounters the close li tag.
We compare against the previously unclosed tag div and see that this is
unexpected. Instead of simply giving up here, we continue to move up the
unclosed tags until we find a match (if there is one).

fix(language-service): Use last child end span for parent without close tag

Unclosed element tags are not assigned an endSourceSpan by the parser.
As a result, the visitor which determines the target node at a position
for the language service was unable to determine that a given position
was inside an unclosed parent. This happens because we update the
endSourceSpan of template/element nodes to be the end tag (and there
is not one for unclosed tags). Consequently, the visitor then cannot
match a position to any child node location.

This change updates the visitor logic to check if there are any
children of a template/element node and updates the end span to be the
end span of the last child. This allows our isWithin logic to identify
that a child position is within the unclosed parent.

[atscott]

presubmit

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}