ModalBar should enforce singleton-ness

[peterflynn]

Various parts of our UI code assume only one ModalBar instance can be open at a time (e.g. using selectors like ".modal-bar .foo" to find pieces of UI). However, Nothing globally tracks ModalBar instances; they only show/hide because of blur events, and often only the ModalBar clients even keep track of those events. They also may animate closed or close on a hack timeout (ahem, QuickOpen) -- which means two ModalBars can briefly be open at the same time. This breaks those assumptions.

I'd like to do a cleanup at some point where we (a) eliminate the QuickOpen hacks, (b) use autoClose in more cases, and (c) let ModalBar keep track of its own instances so it can close the previous instance synchronously before opening a new one. This is a placeholder bug for those changes.

[njx]

Marking medium priority. @peterflynn - I think there are existing known UI bugs that are caused by this - at some point would you mind linking them to this bug (or if they're not already filed, mention the steps here)?

[peterflynn]

The only existing bug I'm aware of is #652:

1. Invoke Quick Open bar
2. Invoke Find or Replace or Find in Files bar

Result: Quick Open bar closes but the other search bar does not open. Works fine in the reverse direction though.

But to prevent a similar bug when switching between Find/Replace <-> Find in Files, we had to put some fairly hacky code in this sprint -- which would be nice to eliminate.