Variable element width support in multiple mode

[dangoodman]

Currently, search input width maintained to take entire room available after selected items if there are. There are apparently two reasons to do that:

1. Show as much of search phrase as possible without getting on a new line
2. Catch all clicks to ui-select element to activate it (show dropdown, etc)

The search input size-related code is built on assumption that there are only internal sources of available room change, like adding or removing choices. That's mostly true if entire ui-select has fixed width. In other case if ui-select width is not fixed there are external things affecting it which we can't control, like parent container size change (due to window resize, for example), or dynamic styles changes (for example, choices might be hidden with css when dropdown is open).

This PR is aiming to make the element working better with variable width:

1. Reduce time when search input is forced to have particular width to cover entire available room. Currently it's forced all the time. With the PR search input is only forcedly sized when ui-select is active. All other time it's sized with CSS. There are built-in width and min-width values which can be easily overridden in user code.
2. More accurately calculate available room for search input with respect to paddings. Get rid of magic numbers.
3. Catch clicks to the entire ui-select surface (free of current choices) to activate it. Currently, if element becomes multiline only clicks to the bottom line caught since that is where search input placed. Clicking on lines above does not take effect. PR fixes this.
4. Make examples in demo-multi-select.html having variable width. It seems there is no need to have them fixed-width now. The demo also shows how's the modified element working.

[DrCool]

+1

[dangoodman]

@dimirc Is the project dead? Only three trivial one-line fixes accepted for about a month. Do you consider it a normal improvement speed? There are a bunch of stalled pull requests fixing real issues. Would it take years to approve them?

[wesleycho]

@dangoodman this project has seen a lot of churn - there are two new maintainers (I'm just triaging a bunch of PRs since I'm in the mood - not really involved in the project).

That said, this needs rebasing.