Support a new YAML format for template settings

This is the initial version of support for a YAML format settings file, to supersede ```cookiecutter.json```. Before committing, I would like to refactor this further, to make the "internal" format completely encapsulated in ```settings.py``` so that client code need have no knowledge of how the settings are stored. But the PR is sufficiently complete that it's ready for initial review.

At the moment, it's only the context data that is in the settings, so the refactoring won't actually impact much, but it establishes the principle that following changes should follow. The main change at this stage will be in the tests, which currently know far too much about how the settings/context is stored.
Hmm, I think we're mostly agreeing, but I think you might not be expecting to split things down as finely as I would. I was looking at things like:
* The template settings (context, encoding, top-level object(s), etc)
* The reader (filesystem, git, hg, and we could add more like Python or zipfiles)
* The renderer (Jinja, but simple templates might not need that - also "none" would be useful for binary files)
* The template - but this just contains a settings object and list of files linked to their renderers. The template's purpose is mostly about organising calling functions in the right order.

A reader would produce a template object, and then "rendering" the template would go through its files rendering each in turn with its associated renderer.

At the moment, that's more complexity than we really need. I'd rather introduce the separation as needed - so at the moment we're working on the user interface for the settings, so it makes sense to encapsulate that. When we want to add a new reader, we factor out the reader functionality then. Similarly when we want to add renderers other than Jinja, we refactor that part.