Refactor OmniBar to address multiple typeahead issues

[Greg Hurrell]

One example, with selected text indicated using [/]:

• Type "test " (autocompletes "Test for [shellshock vulnerability]"
• Add "n" (ie. trying to type "test note")
• Becomes "[Test n]" (ie. everything selected); this is the bug
• Add "o" (replaces everything)
• Becomes "O[pen source projects]"

Another bug, this one for parity with nvALT:

• Type "test " like above
• It should autocomplete to "test [for shellshock vulnerability]" (note the case), even though the original note is "Test for shellshock Vulnerability"
• Instead, it completes to "Test [for shellshock vulnerability]"

I feel like the whole OmniBar logic needs to be rewritten to better model that we effectively we have three pieces of state:

1. What is the entered note title/file?
2. What is the underlying represented title/file (if any)
3. What is the text selection?

At the moment we're conflating (1) and (2) in an implicit way: (1) is stored in input.value and (2) is in this.state.value, and they interact with one another in confusing ways. (3) is stored in the DOM in a write-only way (we never read it, we just write to it).

I think I should try to pull these three pieces of state out somewhere explicit and then centralize the logic for accessing them and modifying them to make it really obvious what is going on.

[Greg Hurrell]

Gonna drop the pri now that the major issue is fixed.

[Greg Hurrell]

Closing this because of the rewrite. Will likely have its own, different bugs. 😂