feat($parse): Allow user-defined literals

[lgalfaso]

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
  Feature
• What is the current behavior? (You can also link to an open issue here)
  It is not possible to add user-defined literals.
• What is the new behavior (if this is a feature change)?
  It is possible to have user-defined literals like Infinity and NaN
• Does this PR introduce a breaking change?
  No
• Please check if the PR fulfills these requirements
• The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• Other information:

Allow user-defined literals.

Close: #9504
Close: #9492

[gkalpak]

Nice one !
LGTM

Unrelated to this PR, I noticed we are copy()'ing a lot while parsing. I guess parsing expressions is not our perfrmance bottleneck, but would it make any noticable difference if we used a more efficient special-purpose copy function ?
@lgalfaso, do you have any insight on this ?

[lgalfaso]

@gkalpak we only copy very small objects (they are always objects with key/value and the value is a primitive), and we do so

• Twice when $ParseProvider is initialized
• Once per occurrence of this and $local

The later we do not use the same as in the process of creating the evaluation function we pollute the parse tree

[gkalpak]

You are right. I somehow thought we were copying on every branch of the primary function (which is not the case). Just ignore the noise 😁