Clean up horrible things in LookupInputWidget
Clean up horrible things in LookupInputWidget

* Separate openLookupMenu() and populateLookupMenu().
  These two called each other, the loop being broken by
  a recursion guard.
* Make openLookupMenu() not close the menu
* Populate the menu on focus, and clear it on blur
* Remove is-focused check from openLookupMenu(), and
  move it to the event handlers where it actually
  makes sense (mousedown and change)
* Implement the is-focused check with a boolean property
  rather than asking the DOM every time
** Not only is asking the DOM slower, it's unreliable:
   in the onFocus handler, $input.is( ':focus' ) is still false
* Remove recursion guard that broke aborting of pending requests
* When closing menu, abort pending requests and clear menu
** Also do this when MenuWidget closes itself (e.g. Esc was pressed)
* Make abort handling more robust
** New code is robust against aborted requests still succeeding
** If a request fails due to being aborted (XHR does this),
   don't close and clear the menu
* Remove totally unused method onLookupRequestDone
* Move empty string handling from getLookupRequest to populateLookupMenu
* Document strange never-resolving promise situation in getLookupRequest
** I kept this in my abort refactor because it seemed like the best
   way to ignore aborts. I'm open to better suggestions.
* Add an explicit way to disable lookups while changing the value
  from a choose/select handler, or while focusing
** This kind of sucks. I tried adding setValueWithoutLookup() instead
   but that didn't work very well either. Open to suggestions.

Bugs fixed:
* While typing, old requests were not being aborted. If you typed
  "E", waited 250ms, then typed "cho", you'd get suggestions for
  "E" rather than for "Echo".
** Fixed by removing recursion guard
** Every character typed now aborts the previous request and
   starts a new one
* Pressing Esc to close the menu while a request was pending did
  not abort the pending request. Once the request came in, the menu
  would open again.
** Fixed by adding toggle handler
** Pressing Esc while the menu is open and a request is pending
   now cancels the request
* Choosing a suggestion caused a new request for that value,
  reopening the menu once those suggestions arrived, unless the
  subclass had hacks in place to prevent this.
** There is now a standardized and documented hack for this
* Focusing the input did not cause the menu to appear, even if you
  focused it by clicking in it. Clicking in it a second time did
  open the menu.
** Fixed by not asking the DOM whether we're focused when
   opening in response to a focus event

Change-Id: Iecae9b58260c20b88118a1bf3bcbd92a6c089b42

wikimedia/oojs-ui,wikimedia/oojs-ui,wikimedia/oojs-ui,wikimedia/oojs-ui