fix($parse): make promise unwrapping opt-in

[IgorMinar]

Previously promises found anywhere in the expression during expression
evaluation would evaluate to undefined while unresolved and to the
fulfillment value if fulfilled.

This is a feature that didn't prove to be wildly useful or popular,
primarily because of the dichotomy between data access in templates
(accessed as raw values) and controller code (accessed as promises).

In most code we ended up resolving promises manually in controllers
anyway and thus unifying the model access there.

Other downsides of automatic promise unwrapping:

• when building components it's often desirable to receive the
  raw promises
• adds complexity and slows down expression evaluation
• makes expression code pre-generation unattractive due to the
  amount of code that needs to be generated
• makes IDE auto-completion and tool support hard
• adds too much magic

Closes #4158
Closes #4270

[mary-poppins]

Thanks for the PR!

• Contributor signed CLA now or in the past
  • If you just signed, leave a comment here with your real name
• PR's commit messages follow the commit message format

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[wilsonjackson]

Thanks @IgorMinar, this does seem like the most sensible solution.

[mhevery]

LGTM

[clakech]

Too bad :(

This will lead to an increase number of line of code in our controller to resolve promises using then/always stuff AND there is no way in angular to deal with race condition if you resolve multiple time a promise but you only want to keep first/last/specific result

This 'magic' was good in my opinion and I would like to know what other native angular feature you will remove in short term that we already use widely in our codebase.

Thank you for all the refactoring stuff I will have to do soon ;-)