The current build/ext folder structure needs to be simplified.

Of Note:

* `ext` has been split up into `assets` and `targets` (in root).
  There is now: `web`, `chrome.extension`, `rim.chrome.extension`
  and `cordova`.
* `build/build` felt quite redundant, so the rest of the files were
  placed in `build/*`. It does not feel 100% ideal due to the specific
  modules that make use of jWorkflow, but it felt better than previous.
* The old chromium/chromestore folders were separated into a less
  confusing structure. `rim.chrome.extension` just copies
  `chrome.extension`'s structure then overwrites any of its
  `target/*` files.

This (in general) will also pave the way to separate `lib`
files (such as UI plugins) per build target.

GitHub Issue:
https://github.com/blackberry/Ripple-UI/issues/444
There should be a CLI based (local) dev workflow for Ripple.

First off, this is a huge commit. You can berate us for it, but
seriously, given the massive changes, it would be maddeningly long to
separate these into a number of commits. In consideration of that, and
because a lot of the bloat is in renames, it seemed ok to include this
as one giant commit.

To summarize, this includes:

* A basic command line interface and parser.
* Ability to install as a NPM package.
* Ability to statically host an app to test (via CLI).
* A proxy server for cross origin XHR calls (rewritten in JS, vs old
  Ruby based one that is currently deployed).
* Re-organization of the main lib/ codebase (and removal of the lib/
  folder).

*Re-organization*

There was many debates on how best to structure the repo, now that it
would have a `cli`, `client` and `server` aspect (and not just be a UI
that is mainly built as a Chrome extension).

By removing the `lib` folder, and placing all the subfolders in the root
of the project repo, this allows for a module to require another module
in a consistent way in both node and a browser env, without needing to
include `lib` in the require path. So, you would require modules like:

    var foo = require('ripple/[client|cli|server]/foo');

*CLI*

After some long debate, and observation of other popular CLI command
structures, we opted to go with this (see `doc/cli/ripple.md`):

    ripple [CMD] [SUBCMD] [OPTION_FLAG] [ARG(S)]

You can check out the CLI usage for more details (in `doc/cli/*`), but
this will be the starting point. Note that there is only one sub command
defined. While the ability to have multiple sub commands is possible,
having only one sub command will enforce a terse (or flattened) command
structure, that can be augmented by flexible flag based options
that can take one or more arguments.

It felt best to go with this approach, compared to other approaches,
such as `[CMD1] [CMD2] [CMD3].. etc.`, because while it can be
very explicit, it lacks an immediate (visual) definition of what
those arguments actully are. Having `--` (or short `-`) flags feels a
more explicit and straightforward. Anoter note to make is that
shorthand flags have been left out (for the time being) for
simplicity's sake, and until a "v1.0.0" public API is finalized.

This is of course still open to discussion. One such avenue for this is
in the callback-dev mailing lists.

    http://markmail.org/message/zngyuhxgihjjzgsw

*Proxy Server*

Previously, the code that was used to support cross origin
XMLHttpRequest calls to any domain (using CORS for http(s) hosted apps,
and JSONP based calls for apps run from file://) was hosted remotely,
and resided in its own repository.

That code can now be thrown away for a JavaScript based version
that now resides in the main Ripple repo (as it should be), and
can be booted via the CLI (individually, so it can be hosted remotely
for users who don't use the CLI locally, and as part of the
`emulate` command). See `server/proxy.js` for the implementation.

*Static App Hosting*

The guts of the initial CLI implementation is in the `emulate` command.
As part of its functionality, it can (locally) serve up a static web
application to test with, which also has a number of services bound
to a specific route that Ripple's (client) UI can make use of
(ex: A cross domain XHR proxy server that is local, vs remote).

Because you can open your app in any browser (but, for the time being,
will need Chrome and Ripple's extension installed) there is a user
friendly URL you can initially navigate to (logged after the `emulate`
command is run) that checks for the correct browser and if the extension
is installed. If not, it displays how/where to get it. It is noteworthy
to say this is inspired by http://emulate.phonegap.com.

For more information, see `doc/cli/emulate.md`.

*NPM Packaging*

Upon build, there will be two new targets in `pkg/*`. `npm` (for
consistency of build) is essentially the root project, that can be
installed. `rim.npm` is our Blackberry based npm package (that requires
a EULA to be accepted before use).

*Of Note*

* The use of `build/scripts/runTestsInNode` is not longer warranted.
* An extra step (npm link) is used in `configure` to make non-relative
  requires work in node (ex require('ripple/*').
* In the client, the cross origin XHR module can now be configured to
  go against a local OR remote URL (or be disabled). See the settings
  panel in the UI to do so (also `client/ui/plugins/settings.js`).
* New NPM package dependencies have been added.
  * express
  * connect-xcors
  * request
  * colors
* Node v0.8.x and NPM 1.1.x or greater is required to configure, build
  and install Ripple (due to current packages used). This felt ok, as
  0.8.x has been out for some time, and if you don't actively upgrade
  to latest.. shame on you! (specified as engines in package.json).
README needs to be updated.

* Added information for the CLI & NPM package portion.
* Added some extra info regarding the standalone version (not being
  maintained).
* Changed developer documentation link to point to `doc` (and not the
  old, outdated docs site).
XHR requests to localhost with different ports should be proxied.

Ex: localhost:4000 does an XHR request to localhost:4001.

Currently, the XHR wrapper will not consider this a non local request,
which is wrong.

This also cleans up the logic to be more straightforward, and removes
the stupidly long external uri regex we were using.