fix(ngOptions): fix frozen ui in ie with more than one select[multiple]

[Narretz]

If there are more than one select, and the first select is wrappend
in an element with display: inline or display: inline-block, all but
the last select are completely unresponsive to any user input.

This cannot be tested in a unit-test, as the events must come directly
from the ui.

Close #11314

This is pretty tricky, as we probably need an e2e test for this, but they currently don't run on IE. I'm also not sure if we can simply leave the label setting out.

@petebacondarwin should we wait with this until we have IE e2e tests?

[petebacondarwin]

If you can see that this fixes the bug on IE and that we are not breaking other browsers by removing then we should merge this. I am trying to remember why both assignments are there in the first place. I have a feeling it was getting around another IE bug.

[Narretz]

Looks like you are right:

IE 9.0.0 (Windows Vista) ngOptions should update the label property FAILED
    Expected '' to equal 'A'.
    Expected '' to equal 'B'.
    Expected '' to equal 'C'.
IE 9.0.0 (Windows Vista) ngOptions should update the label if only the property has changed FAILED
    Expected '' to equal 'A'.
    Expected '' to equal 'B'.
    Expected '' to equal 'C'.
    Expected '' to equal 'X'.

[petebacondarwin]

So we need to find a different solution...

[Narretz]

I haven't looked into a different solution, but I created an e2e test - which doesn't work. It's seems like this is essentially untestable. I have this spec to click on an option inside a select:

it('should be able to select the first select', function() {
    loadFixture("ngOptions").andWaitForAngular();
    element(by.cssContainingText('option', 'two')).click();
    expect(element(by.binding('selected1')).getText()).toBe('two');
  });

and this works! But the bug is that actual clicks from the ui don't work at all on the first select. So we can't even show the bug with an e2e test.