perf(ngOptions): use documentFragment to populate select

[Narretz]

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
perf/fix

What is the current behavior? (You can also link to an open issue here)

• ngoptions is slow in ie with many options
• strange freezes in ie in some cases

Does this PR introduce a breaking change?
a tiny one possibly - now the select element is completely emptied before the options are appended

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:

This changes the way option elements are generated when the ngOption collection changes.
Previously, we would re-use option elements when possible (updating their text and
label). Now, we first remove all currently displayed options and the create new options for the
collection. The new options are first appended to a documentFragment, which is in the end appended
to the selectElement.

Using documentFragment improves render performance in IE with large option collections
(> 100 elements) considerably.

Always creating new options fixes issues in IE where the select would become unresponsive to user
input.

Fixes #13607
Fixes #12076

[petebacondarwin]

I checked this with the ngOptions benchmark the project and there is no discernable difference in speed on Chrome, Firefox or Safarin on OS/X. So I am happy to go with using this much simpler (and less buggy when it comes to IE) algorithm.

[petebacondarwin]

@Narretz please merge into master and 1.5.x

[Narretz]

Just noticed that it should be possible to create the documentFragment only once per ngOptions (instead of once per update), as the fragment contents are removed once it has been appended to a container

[gkalpak]

So, except for a couple of minor (ignorable) comments it LGTM.
I wonder if it might break people's test (the same way it broke ours).

[Narretz]

Wrt to the tests - maybe. But the test was only working before because it relied on the implementation (option elements are reused). And tests shouldn't do that.