Destroy machine when last principal unit removed.

This change causes a machine to be automatically removed when the last principal unit running on that machine is removed (remove-unit). If the machine is a parent to any containers, it is left alone.

Background:
https://bugs.launchpad.net/juju-core/+bug/1206532
https://bugs.launchpad.net/juju-core/+bug/1183309/comments/8

This could use more test coverage, but I'd like to get a general feel for how it's looking so far before I go much further with it. This is my first time mucking around with state transactions. Please let me know if I've got it right!

I haven't added an option to keep empty machines/containers around after removing the last unit. I'd like to see if we can avoid it. If we do need the option, I think it should be opt in. Let me know.
Ah, I see. This will work in the specific tests you wrote, in which the unit has never set a status; and is therefore assumed not to have created subordinates, or to have entered relations, and can therefore be blown away directly, rendering the machine-destruction functional.

But regardless, we can't just defer this, there are too many ways to fail (assume the conn could go down, the process could get killed, whatever -- at any line). The way to Do It Right is:

  * in service.removeUnitOps, check whether the machine is eligible for destruction (ie the *only* principal it has is the unit being removed (and there are no containers, or votes, or other reasons).
  * if it is eligible, add the machine-destroy ops to the transaction
  * if it is not eligible, add ops that assert that it is still not eligible when the txn runs
  * if the transaction fails, refresh the machine and rebuild from scratch against latest known state

...and, now, at long last, we actually have the ability to test this in detail. Search for TransactionHook to get a mechanism that lets you make arbitrary changes to state just before and after particular transactions run, thus letting you simulate and validate the worst case you can imagine: eg

 1. unit is alone on machine, gets destroyed
 2. *just* before the txn is applied, a container is added to the machine, causing the txn to fail
 3. *just* after the txn fails, the container is removed, so the original txn gets rebuilt identically
 4. *just* before the retry, a unit is assigned to the machine
 5. do nothing after the retry, txn gets rebuilt against current state (ie asserting that the machine is not eligible for destruction)
 6. *just* before the next retry, remove the unit and add a container
 7. expect success, because the machine is *still* not eligible for destruction, even if the precise manner in which it is ineligible has changed.

If you can construct and pass that test case (or equivalent ;)) I'll be very happy indeed.