Handle cases where default-series is problematic.

If the bootstrap node is not the default (currently precise) then it is bad
for deploying the Juju GUI since the charm is only currently available for
precise.

If an environment is already booted to non-precise or the default-series is
set to something other than precise then special care needs to be taken.  All
of the scenarios are summarized in this note:

http://bit.ly/1cXiPIW

The three QA steps will all re-use the following command to invoke Quickstart:

% .venv/bin/python juju-quickstart \
   --gui-charm-url cs:~juju-gui/precise/juju-gui-136 \
   bundle:~bac/muletrain/6/wiki

All of the following use ec2, so:

% juju switch ec2

1) No default-series.

Destroy any existing environment.
Edit ~/.juju/environments.yaml and comment out default-series for ec2.
Run Quickstart as above.

Expect: Three machines (BSN and GUI on 0) all precise.


2) Non-precise default-series

Destroy any existing environment.
Edit ~/.juju/environments.yaml and set 'default-series: raring' for ec2.
Run Quickstart as above.

Expect: Four machines
        0 - bootstrap node, raring
        1 - GUI, precise
        2 & 3, bundle services, precise because that's what their charms are.

Look at the output generated.  You should see

setting the default-series to raring

Also do a
% juju get-env
The default-series should be raring.


3) Existing environment with non-precise.

Destroy any existing environment.
Edit ~/.juju/environments.yaml and set 'default-series: raring' for ec2.
% juju bootstrap
Run Quickstart as above.

Expect: As #2 without the message about setting the default-series.

R=gary.poster
CC=
https://codereview.appspot.com/37320043