Vimium Omnibox implementation, with fuzzy completion

As seen in #442, this pull requests suggests a sophisticated new UI and infrastructure that allows for efficient, keyboard-controlled navigation of history items, bookmarks, tabs and for user-defined commands like web search, URL input and accessing different search engines.

Parts of the changes included in this request *could* be applied on their own (for example the changes to `lib/utils.js`), but this wouldn't be of a significant advantage within the context of the existing Vimium code base. The approach I take is therefore to suggest all the changes as a whole and explain how they are structured.

### Motivation

I really like Vimium in its current state, but what I always missed about it was a really efficient way to navigate away from a page. The Omnibox is quite good, but I find it's a pain to use it with Vimium, as pressing Ctrl+L causes the current page to lose focus, which defeats almost all of Vimium's bindings. Returning focus to the page is near impossible without using the mouse. Also, the Omnibox is not as configurable as I like it to be. It doesn't do fuzzy matching (which I love and use a lot inside vim), doesn't help in searching lost tabs and adding search engines is a bit of a pain. One more reason is that the location bar takes away vertical space, which I have better use for on my laptop screen.

### Changes to the existing library code

* `background_page.html`: added new background API elements to access bookmarks, history and tabs from content scripts
* `lib/utils.js`: refactored the existing URL detection to be a bit more useful. Also added some helpers I needed that I think are general enough to be included here
* `lib/keyboardUtils.js`: Handle uppercase input (don't know why this wasn't the case before, maybe it's not the right thing to add this here)

### Logic for different kinds of completion

The underlying model is a simple one. A completion driver is something that gets input and returns a list of suggestions together with a rendering routing to transform them into HTML and with a relevancy value. There are 5 different drivers already implemented:

* smart: A driver that takes an input string and tries to make sense of it. It tries to detect whether the input is

    * a user-defined command (`wiki Obama`) => suggests to evaluate the command
    * an URL => suggests to visit it
    * nothing special at all => suggests a basic web search

* bookmarks, history, tabs: they fuzzy match the different kinds of items
* merging completer: a driver that can be used to combine and sort the results of multiple driver instances

The library code includes a comprehensive class to manage fuzzy string matching which implements filtering and ranking, together with some basic optimization like result caching.

I think this approach is very flexible and can be extended for other use cases as well.

### User interface

The user interface is a simple HTML box which takes input and presents the results returned by the underlying completion driver. It is designed to be easily readable, with a rather large font and dark background for maximum contrast (although the styling is only a matter of CSS, of course):

![](http://dl.dropbox.com/u/3687640/fuzzy4.jpg)

### Example integration

As a suggestion, three Vimium commands are implemented to demonstrate the usefulness of this addition:

* Generic complete (bound to `o` => open in current tab, `O` => open in new tab). Fuzzy-matches history, bookmarks, tabs and uses the smart completer to suggest sensible actions depending on input
* Tab complete (bound to `T`). Fuzzy-matches open tabs in the current window for people who never close tabs and therefore got lots of them open at the same time (like me)

### Maintenance

I am aware that this pull request, with its 700 LoC+, is pretty large, compared to the existing combination of `completionDialog.js` and `bookmarks.js`, which together have under 300 lines. However, my approach has the advantage of unifying different kinds of dialogs, which makes it easy to drop, add or recombine functionality in the future.

I am also aware that the maintainers of this project keep a focus on efficiency and maintainability. I did my best to improve usability and responsiveness of the UI and to add documentation for the significant pieces of code, but I am convinced that my code in the current state leaves room for improvement. If this gets a chance, I will put some effort into code reduction. I am also willing to support and improve this facility in the future, if that would be of help. Hacking Vimium is really fun :)