Update machine model.

Include new info from the mega-watcher for machines.

QA:
- Bootstrap an ec2 environment with juju-core trunk (at least revno 2463):
  `juju bootstrap -e ec2 --upload-tools`.
- Deploy and expose the GUI:
  `juju deploy -e ec2 juju-gui && juju expose -e ec2 juju-gui`.
- Switch to this branch:
  `juju set -e ec2 juju-gui juju-gui-source="https://github.com/frankban/juju-gui.git machine-model-changes"`.
- Wait for the unit to be ready, log in and open the JS console.
- Check that two machines are present in the db:
  `app.db.machines.size();` --> 2.
- Inspect the GUI machine:
  `app.db.machines.getById('1');`.
- Check the returned fields, i.e. check that the machines properly includes:
  - four addresses (name is empty for now);
  - hardware characteristics (arch, cpuCores etc. in the hardware property);
  - jobs ('JobHostUnits');
  - life ('alive');
  - series ('precise');
  - supportedContainers ('lxc').
- Check that the bootstrap node also manages environments:
  `app.db.machines.getById('0').jobs;`
- Now create a new machine:
  `juju add-machine -e ec2 --series saucy`.
- And we have three machines:
  `app.db.machines.size();`.
- Check the new machine attributes multiple times:
  `app.db.machines.getById('2');`.
- You should see that supportedContainers is initially null, and then it will
  switch to ['lxc']. Also, series is 'saucy'.
- Let's add a container to machine 2:
  `juju add-machine -e ec2 lxc:2`.
- Retrieve information on the new container:
  `app.db.machines.getById('2/lxc/0');`
- You should see that initially hardware is an empty object and also
  supportedContainers is null.
- Wait until the container is fully provisioned (this can take a while):
  supportedContainers is an empty list and hardware include the architecture.
- Note that containers' addresses are not present because they are not
  returned by the cloud provider. The juju db also stores addresses returned
  by the machine itself. A change to juju-core is required if we find out
  we need to know LXC addresses.
- Done, destroy the environment, thank you!
Bug #1290312 - Add trash icon and click target.

The entire relation popover is no longer a click target. Instead there's
a trash icon which will trigger a remove function. Eventually the
service names in the relation will also become click targets to open
that service in the inspector.
Convert the changeSet data structure to a flat structure with key references to parent commands.
Merge pull request #195 from kadams54/relation-popover

Excellent. Thanks for the review! :shipit:
Merge pull request #194 from frankban/machine-model-changes

Include new info from the mega-watcher for machines.

QA:
- Bootstrap an ec2 environment with juju-core trunk (at least revno 2463):
  `juju bootstrap -e ec2 --upload-tools`.
- Deploy and expose the GUI:
  `juju deploy -e ec2 juju-gui && juju expose -e ec2 juju-gui`.
- Switch to this branch:
  `juju set -e ec2 juju-gui juju-gui-source="https://github.com/frankban/juju-gui.git machine-model-changes"`.
- Wait for the unit to be ready, log in and open the JS console.
- Check that two machines are present in the db:
  `app.db.machines.size();` --> 2.
- Inspect the GUI machine:
  `app.db.machines.getById('1');`.
- Check the returned fields, i.e. check that the machines properly includes:
  - four addresses (name is empty for now);
  - hardware characteristics (arch, cpuCores etc. in the hardware property);
  - jobs ('JobHostUnits');
  - life ('alive');
  - series ('precise');
  - supportedContainers ('lxc').
- Check that the bootstrap node also manages environments:
  `app.db.machines.getById('0').jobs;`
- Now create a new machine:
  `juju add-machine -e ec2 --series saucy`.
- And we have three machines:
  `app.db.machines.size();`.
- Check the new machine attributes multiple times:
  `app.db.machines.getById('2');`.
- You should see that supportedContainers is initially null, and then it will
  switch to ['lxc']. Also, series is 'saucy'.
- Let's add a container to machine 2:
  `juju add-machine -e ec2 lxc:2`.
- Retrieve information on the new container:
  `app.db.machines.getById('2/lxc/0');`
- You should see that initially hardware is an empty object and also
  supportedContainers is null.
- Wait until the container is fully provisioned (this can take a while):
  supportedContainers is an empty list and hardware include the architecture.
- Note that containers' addresses are not present because they are not
  returned by the cloud provider. The juju db also stores addresses returned
  by the machine itself. A change to juju-core is required if we find out
  we need to know LXC addresses.
- Done, destroy the environment, thank you!
Fixed tests fro the changeSet data structure conversion
Merge pull request #196 from hatched/ecs-flat-structure

This branch changes the changeSet data structure from a tree to a flat structure with reference to it's parents. At the moment it executes them top down but in follow-up branches I will implement the 'wait for parent' procedure.

#### To QA
- Load the GUI using the `ecs` flag
- Drag and drop ceph and click deploy once.
- Open the console and run `app.ecs.changeSet` and you should see a single record. Take note of the key name.
- Execute, substitute the previous key for the service name: `app.ecs.setConfig('service-xxx', {'http-port': "80802"}, null, {'http-port': "8080"}, function() {});`
- Run `app.ecs.changeSet` and you should now see two records.
- Run `app.ecs.commit()` and your charm should now be deployed.