Allow client to be injected and run in any (web) browser.

This means you can inject Ripple's client UI into any (hosted) app,
provided you use the CLI's `emulate` cmd, so you need to:

a) Be running locally with the npm package installed.

or..

b) Be running remotely with the npm package hosting your content.

To emulate your app in a browser (ex: Safari), do something like this:

    cd ripple-repo
    jake && ./bin/ripple emulate --path to/your/app

Then, open a web browser at the location logged to console, but with the
`enableripple` query string param (as used in the Chrome Extensio):

Ex:

    http://localhost:4400/index.html?enableripple=true

This will inject the client UI in the same way the Chrome Extension
does.

Note: Currently, Ripple will attempt to inject itself on any .html file
      with a `<head>` tag in it.

Note: This only works (at the moment) in select browsers (ex ones that
      have WebSQL). Browsers like FireFox is a TODO.

Note: Updated the README to talk about using the hosted version, and
      removed the reference to the `pkg/web` target (which is no
      longer needed now that you can use the `pkg/hosted` target).

Authored By:

    Brent Lintner <brent.lintner@gmail.com>
    Bryan Higgins <bhiggins@rim.com>
The `cordova` build target can be removed.

This is because it was a proof of concept, is not primarily used, and is
also not kept up to date.
WebSQL is a deprecated spec.

It is not even supported in browsers like Firefox.

Let's go back to localStorage if `window.openDatabase` does not exist.

Note: Also tweaked removeAll and re-enabled a `xit` db test.
`innerText` is not a standard (DOM) spec.

Use `innerHTML` instead, as some browsers may not support `innerText`.
Emulate a remote (proxied) website using the hosted build target.

You can now (in addition to the `--path` option) enable over a remote
website (app). Ex:

    ripple emulate --remote http://foo.com

Then navigate to (what is logged):

    http://localhost:PORT

Which should load the remote site as it should be.

To enable Ripple's client UI around it, you can add the enableripple
query param:

    http://localhost:PORT?enableripple=true

Note: This is NOT perfect. Some tweaks will be needed.
Update Express to a non RC version (3.0.4).
A mobile website should be sent the proper user agent (server side).

When running a command like so:

    ripple emulate --remote http://foo.com

Then navigate to something like:

    http://foo.com?enableripple=true

When enabling for that page, the current userAgent of the current
device (according to client side db) will be sent to the server and
used instead of the browser's.

Note: This does not cover some edge cases, such as having links with
hardcoded host names in them.

Note: Also cleaned up the current navigator.userAgent (client side)
emulation to be more simple (i.e. if userAgent on the current device is
falsy, use original).

TODO: This could use some cleanup/refactoring.
The `pkg/web` build target is no longer warranted.

This build target is no longer (primarily) used, and now that there is a
hosted build target, which can function without the chrome extension
(i.e. standalone) this is no longer needed, and should be removed.

This also cleans up some hacky (complexity inducing) code (such as the
omnibar checks) that has never felt right.
There were some incorrect (relative) image paths in the main css file.

It did not cause any visible breakages in the Chrome Extension build
target, but in the hosted version (where assets are loaded from
`ripple/assets`) it shows up.