fix($parse): deprecate promise unwrapping and make it an opt-in

This commit disables promise unwrapping and adds
$parseProvider.unwrapPromises() getter/setter api that allows developers
to turn the feature back on if needed. Promise unwrapping support will
be removed from Angular in the future and this setting only allows for
enabling it during transitional period.

If the unwrapping is enabled, Angular will log a warning about each
expression that unwraps a promise (to reduce the noise, each expression
is logged only onces). To disable this logging use
`$parseProvider.logPromiseWarnings(false)`.

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
or automatically via routing and unifying the model access in this way.

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

BREAKING CHANGE: $parse and templates in general will no longer
automatically unwrap promises. This feature has been deprecated and
if absolutely needed, it can be reenabled during transitional period
via `$parseProvider.unwrapPromises(true)` api.

Closes #4158
Closes #4270
revert: fix($parse): handle promises returned from parsed function calls

This reverts commit 3a65822023119b71deab5e298c7ef2de204caa13.

The change cased regressions in third party components that require
promises from getter functions not to be unwrapped.

Since we have deprecated the promise unwrapping support in $parse it
doesn't make much sense to fix this issue and deal with regressions in
third party code.

Closes #4158
fix(jqLite): ignore class methods on comment elements

Since c785267e jqLite uses setAttribute (rather than className property) in order to change classes. Some elements (eg. Comment) do not have this method which blows up.

jQuery silently ignores these method calls (because it uses className), so to get the same behavior as jQuery, we check for setAttribute method first.
feat(ngRepeat): use block separator comments

Issue: multi-elements ng-repeat (ng-repeat-start, ng-repeat-end) can contain elements with a trancluding directive. This directive changes content of the row (template) and ng-repeat does not work correctly (when removing/moving rows), because ng-repeat works with the original template (elements).

This changes ng-repeat behavior to traverse the DOM to find current elements everytime we are moving/removing rows (if the template has multiple elements).

Closes #3104
fix(modules): stop leaking global variables in tests

The routeUtils.js file was declaring a number of functions that were
leaking into other modules such as ngMocks causing tests to pass
incorrectly.