Add end_location annotations for parse trees

[richcarl]

Based on #3020.

This allows the quoted source code in error messages to underline the range of the error, and can also be used by tools that display source code, as in an IDE.

Example:

foo.erl:18:16: illegal guard expression
%   18| foo(A, B) when is_lit(A), is_list(B) ->
%     |                ^^^^^^

instead of just

foo.erl:18:16: illegal guard expression
%   18| foo(A, B) when is_lit(A), is_list(B) ->
%     |                ^

This has only been implemented on the parser level. Adding further support for the scanner to annotate all tokens with end position right away would save the time now spent calculating end positions of tokens by taking the length of the text.

[gomoripeti]

Dear OTP team,

Allowing end_location key as a first class citizen in erl_anno:anno() and the addition of erl_anno:set_end_location/2 would be beneficial in itself.
I started to need this since f30514e#diff-9f3b412e8fbd809c6473fcd5bee30f63931c7349010640d76316cfcde504e733
where erl_syntax:set_pos started to require a proper erl_anno:anno() instead of any term.
Even if the parser or OTP tools don't use it, other tools could store end_location annotation (without text).
This is not a major issue, but only to make dialyzer and erl_anno:is_anno/1 happy.

Would the OTP team be open to include only the erl_anno changes of this PR in OTP 24 or is it too late?
(minor benefit of including the set_pos and this change in the same release would be that there is a way before OTP 24 and from OTP24 to store start and end location in erl_syntax:set_pos, without a gap)

[garazdawi]

We are not certain that end_location is the best way to represent ranges in the AST, so we do not want to make a commitment to that design before we know.

[gomoripeti]

makes sense, thanks for the response
(out of curiosity what alternatives or drawbacks of end_location came up? I can think of text for all abstract format, not just some leafs)

[garazdawi]

I don't recall what the exact reasons were, but the alternative approach that we have been talking about is including the text that a node represents in anno, or something like that. We are not actively working on this, so my memory is a bit rusty.