Add new HighAvailabilityFacade for new ensure-availability command
go fmt
Tweak NewClient to improve testability
cmd/jujud: rationalised version number handling in upgrade-steps worker

1. Use version.Number's in logs and status output throughout instead
of version.Binary's. The series and architecture is irrelevant to the
upgrade process and including it just adds unnecessary verbosity.

2. The check for an already completed upgrade has been moved earlier
to avoid unnecessary initialisation.

3. New upgradeWorkerContext attributes have been added to make the
from version more accessible and the target version shorter to read
and write.
cmd/jujud: refactored upgrade logic

This revision is primarily about splitting up runUpgrades into smaller
pieces. This function was getting to be too large and difficult to
follow.
Merge pull request #732 from mjs/upgrade-sync-refactoring

state server upgrade sync refactoring

Various clean ups for the recent state server upgrade synchronisation work.
Merge branch 'master' into ensure-availability-to
Merge master, resolve conflicts
Code review tweak
Fix tests
Merge pull request #737 from wallyworld/ensure-availability-to

New HighAvailability facade

We need to add placement directives to the ensure-availability command. Hence we need to modify the API. As with most client APIs, there's one big facade. This doesn't lend itself to API versioning very well. So a new HighAvailability facade is introduced. This adds to our other existing client facades like KeyManager, UserManager etc.

Most of the changes are moving existing functionality from client -> highavailability packages. The client facade retains shims to redirect calls to the new facade.

The ensure-availability command detects whether the new facade is available and uses it if possible.

The next branch will actually do something with the placement directives.