Created local charm new or upgrade inspector.
Update shrinkwrap to fix missing zipstream-ctalkington dependency.

Also removed a broken test.
Merge pull request #147 from frankban/fix-npm-deps

Regenerated the shrinkwrap file.
Also removed a broken test.

QA:
- remove your npm cache;
- make clean-all;
- make;
AddMachines and DestroyMachines API calls.
Merge pull request #148 from frankban/machines-api

AddMachines and DestroyMachines API calls.

Implement the machine related API calls.

QA:

Bootstrap an ec2 environment using juju-core trunk
(creating lxc inside lxc did not work in my saucy machine,
and also note core trunk does not support kvm at this time):
  juju bootstrap -e ec2 --upload-tools

Deploy and expose the GUI:
  juju deploy -e ec2 juju-gui --to 0
  juju expose -e ec2 juju-gui

Enable the GUI console and switch to the current branch:
  juju set -e ec2 juju-gui juju-gui-console-enabled=true juju-gui-source="https://github.com/frankban/juju-gui.git machines-api"

When the GUI is ready, log in and open the JavaScript console.

Define the following callback that will help visualizing
the data returned by the API calls:
  var callback = function(data) {console.log(data)};

Add two new machines, the first having the default series,
the second being a saucy one:
  app.env.addMachines([{}, {series: 'saucy'}], callback);

With `juju status -e ec2` you should see the two new machines
being created. Check the series is what you specified,
and check the names in the JS response is what's expected.

Make an invalid call to ensure juju-core errors are
properly reported:
    app.env.addMachines([{series: true}], callback);

Call addMachines without passing params, to ensure
the call is stopped before hitting the server:
    app.env.addMachines([], callback);

Now let's create containers. Create one lxc in machine
2 and a another one in a new machine:
    app.env.addMachines([{containerType: 'lxc', parentId: '2'}, {containerType: 'lxc'}], callback);
The response should contain a machines array with including
"2/lxc/0" and "3/lxc/0" names.

Destroy machine 1 and 3:
    app.env.destroyMachines(['1', '3'], false, callback);
You should see an error:
some machines were not destroyed: machine 3 is hosting containers "3/lxc/0";
Machine 1 should be gone.

Try harder to destroy machine 3:
    app.env.destroyMachines(['3'], true, callback);
This time machine 3 should correctly be removed.

Destroy the lxc on machine 2:
    app.env.destroyMachines(['2/lxc/0'], false, callback);

Let's create two new containers on machine 2,
this time with a different series:
    app.env.addMachines([{containerType: 'lxc', parentId: '2', series: 'raring'}, {containerType: 'lxc', parentId: '2', series: 'quantal'}], callback);
Check everything is ok.

Finally, let's create a new machine with four cores:
    app.env.addMachines([{constraints: {'cpu-cores': 4}}], callback);
Check the machine 4 with four cores is being created.

Done, destroy the environment, thank you!
Fix local charm deployed twice in sandbox.
Merge pull request #149 from frankban/bug-1285223

Fix local charm deployed twice in sandbox.
Handle the case when the charm already exists in the charms db.
No QA required.
Refactored local charm upload helpers to support multiple service upgrades
Merge pull request #150 from hatched/upgrade-new-inspector

__To QA__
- Deploy a local charm to sandbox
- Navigate around the inspector, opening closing, viewing charm details etc (exploratory)
- Drag and drop the same local charm zip
- You should get an inspector that has the Request Series view on top and the new Upgrade Services view on the bottom.

__Notes__
Part 3 will hook up the upgrade. It needed the fakebackend fix to land first.