[r=fwereade] state: aggressive removal of pending units

In response to lp:1190715, we make the following changes:

  * service destruction now adds a cleanup doc that churns through all a
   service's units destroying or removing them where possible.
  * unit destruction short-circuiting is now attempted when the unit agent
   has not yet set a status.

...and make the following opportunistic changes for sanity's and clarity's
sakes:

  * clarify and make consistent the similar transaction-building loops
   in service.go and unit.go (in particular, Unit.Remove was noticeably
 simplified).
  * resolve races around unit destruction in which charm changes and
   machine assignment changes are not properly taken into account.

...supported by testing changes as follows:

  * added SetRetryHooks for verifying a commonly-interesting-to-test
   scenario (set up txn; break txn; verify effect of retried txn)
  * SetBeforeHook became SetBeforeHooks, because that happened while I
   was figuring out SetRetryHooks, and I decided it was a nice change.
  * preventUnitDestroyRemove is much simpler and no longer needs the
   state argument; this is annoyingly noisy.
  * assertUnitLife and assertUnitRemoved were taken off UnitSuite and used
   elsewhere.

The macroscopic effect of this is currently limited. Units that are manually
removed will be removed more quickly more often, which is nice; but the big
problem in lp:1190715 is related to service destruction, and that's not
directly helped by this branch.

When we merge a cleanup worker integration branch, though, this bug will be fixed pretty nicely for all environments running this code (on both client and server).