initial design sketch for #796

#796 
I've been considering a few different ways of doing this and proposed the changes here as an initial design sketch as a way of converting Fig YAML to Flocker YAML in a reasonably un-intrusive way (it doesn't break loads of existing tests and application logic)

This takes the logic for detecting a Fig compatible config out of `flocker.node._config` and instead has the check done in `flocker.cli.script`

Then `model_from_configuration` has been altered to take an `application_configuration_format` argument which defaults to `flocker` - if `fig` is supplied as this parameter, the `application_configuration` is treated as a `FigConfiguration` object and parsed. This avoids `flocker.cli.script` instantiating a `FigConfiguration` object while another is also instantiated in `flocker.node._config`. instead I've changed what gets passed between methods.

If we have a Fig config, we can convert it to Flocker YAML and set that converted YAML as the option that gets passed to `flocker-changestate`.

There are other options I can think of for doing this task and this is a pretty much off-the-top-of-my-head first run, so if you don't like this approach, please feel free to tell me :)
I suggest changing the signature of `model_from_configuration` in a different way.  Instead of adding a new `application_configuration_format` argument, change `application_configuration` so that it accepts a `dict` like the one returned by `FigConfiguration` and `Configuration._applications_from_flocker_configuration`.  Then, pass `fig_configuration.applications` as the value here.

Below, in the else clause where we know we have a Flocker configuration instead, invoke the config parser for the Flocker-style configuration and pass the `dict` that results from that.

This approach removes the need to have fig/flocker checking anywhere else.  We can limit knowledge of the choice between fig and our format (or other formats, even) to this one function.

As a first step towards this, it probably makes sense to refactor the parser for our application format into an API like `FigConfiguration` so that it can more easily be used by this codepath.  This will also have the nice consequence of separating the implementation of our deployment config parser from our application config parser (which are currently part of just one class).  I suggest doing this refactoring in a separate branch to ease of review.