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 :)
If this is meant as a unit test for `FigConfiguration.is_valid_format` then it probably belongs on a different TestCase class.  I think that method already has unit tests, though, so that's probably not what's meant here.  I can't quite tell what is meant from the docstring, though.  I suspect this might not be an interesting case to test, though.  As far as `DeployOptions` goes, we don't really care about the `FigConfiguration`.  We just want `DeployOptions` to work right.  So `test_config_fig_converted_to_flocker_yaml` is probably going to cover the important case related to fig input, here.