revert(select): avoid checking option element selected properties in render

This reverts commit dc149de9364c66b988f169f67cad39577ba43434. That commit fixes a bug caused by
Firefox updating `select.value` on hover. However, it
causes other bugs with select including the issue described in #7715. This issue details how
selects with a blank disabled option skip to the second option. We filed a bug
with Firefox for the problematic behavior the reverted commit addresses
https://bugzilla.mozilla.org/show_bug.cgi?id=1039047, and alternate Angular fixes are being
investigated.

Closes #7715 #7855
test(select): add test against updating selected property on digest with no change event

Commit dc149de9364c66b988f169f67cad39577ba43434 was reverted to fix regressions #7715 and #7855.
This commit introduced this test case and a corresponding fix for preventing the update of the
selected property of an option element on a digest with no change event. Although the previous fix
introduced regressions, the test covers a valid issue and should be included.
test(select): add test cases for selects with blank disabled options

An earlier commit dc149de9364c66b988f169f67cad39577ba43434 caused an error where the first option of
a select would be skipped over if it had a blank disabled value. These tests demonstrate that with
that commit in place, blank disabled options are skipped in a select. When the commit is reverted,
the correct behavior is seen that the blank disabled option is still selected in both selects
marked with required and those that have optional choices.

Relates to #7715
test(select): add test of updating the model because of ng-change

A regression #7855 was introduced by
https://github.com/angular/angular.js/commit/dc149de9364c66b988f169f67cad39577ba43434
This test ensures that reverting that commit fixes this regression.
In the regression, changes to a bound model in ng-change were not propagated back to the view.

Test for #7855
test(select): add extra expectations and comments for clarity
fix(select): do not update selected property of an option element on digest with no change event

The `render()` method was being invoked on every turn of the digest cycle,
which was inadvertently updating the DOM even when a `change` event had
not been triggered.

This change only calls the `render()` method when `ctrl.$render()` is called,
as part of the NgModelController` lifecycle and when the `modelValue` has
significantly changed.

Closes #8221
Closes #7715
docs(input): fix small grammatical error

Closes #8422
perf(Scope): remove the need for the extra watch in $watchGroup

Instead of using a counter and an extra watch, just schedule the reaction function via $evalAsync.

This gives us the same/similar ordering and coalecsing of updates as counter without the extra
overhead. Also the code is easier to read.

Since interpolation uses watchGroup, this change additionally improves performance of interpolation.

In large table benchmark digest cost went down by 15-20% for interpolation.

Closes #8396
chore(Scope): remove deregisterNotifier feature for $watch

We no longer have a need for this feature that was added to primarily support
$watchGroup (see previous commit).

BREAKING CHANGE: deregisterNotifier callback for $watch is no longer available

This api was available only in the last few 1.3 beta versions and is not
very useful for applications, so we don't expect that anyone will be affected
by this change.
refact(select): don't recreate selectedSet on every digest loop

In the case of a "multiple" select, the model value is an array, changes
to which don't get picked up by NgModelController as it only looks for
object identity change.

We were rebuilding the `selectedSet` (a hash map of selected items) from
the modelValue on every turn of the digest. This is not needed as we can
simply use `$watchCollection` directly on the `$modelValue` instead.
feat(jQuery): upgrade to jQuery to 2.1.1

The data jQuery method was re-implemented in 2.0 in a secure way. This made
current hacky Angular solution to move data between elements via changing the
value of the internal node[jQuery.expando] stop working. Instead, just copy the
data from the first element to the other one.

Testing cache leaks on jQuery 2.x is not possible in the same way as it's done
in jqLite or in jQuery 1.x as there is no publicly exposed data storage. One
way to test it would be to intercept all places where a jQuery object is created
to save a reference to the underlaying node but there is no single place in the
jQuery code through which all element creation passes (there are various
shortcuts for performance reasons). Instead we rely on jqLite.cache testing
to find potential data leaks.

BREAKING CHANGE: Angular no longer supports jQuery versions below 2.1.1.