Rework deployment to require mysql before keystone

Fixes bug where keystone never deployed correctly, because it waited
for mysql but was incorrectly marked as being deployed anyway.

Includes multiple changes to do so:

## charm.setup() changes
Change Charm.setup() to always explicitly return success or failure*,
and check it in the initial deploy. Currently it was only checked in
the charm queue, which is not used in the initial deploy.

 * - failure to issue deploy. we don't know about deploy results here.

If setup() returns True (aka error or defer), _process() does not add
the charm to the list of deployed charms and instead returns True to
keep polling. This waits for mysql to be available before deploying
keystone.

Change all charms with custom setup() functions to explicitly return
an error / success bool. (This also fixed a latent bug in the unused
ceph charm which had an empty return on errors, which would've
returned None, ie, not an error)

Does not handle exceptions in setup(), I'm assuming they are
considered to be fatal.

## gui.py changes: Reorders deploy priorities and ordering

mysql should deploy before keystone, which deploys before others.

keystone waits for mysql to be *up*, not just deployed, before
deploying and unblocking the rest.


## more logging
Adds logging
Also adds code to make reading logs easier when they have multiple executions, like marking the start of a run.

## allows deploying more than 9 services
removes hardcoded '9' for list of services to attempt to deploy.
in my testing, self.done is sufficient, I'm not sure why the number was added.

This bit is the main fix in this PR - the keystone charm was checking for mysql, then returning True to indicate it wasn't ready to deploy -- but the return code was ignored here. The charm queue used it, but this code didn't.