Dockerfile for CKAN

## What is this?

**This pull request is a continuation of the discussion in #1724**

This PR adds a Dockerfile and support files (including nginx and postfix configuration) for a binary CKAN docker image. Specifically, this allows you to build a docker image including CKAN, running behind nginx and mod_wsgi, by running

    docker build .

For example, to build an image called `ckan/ckan`, you might run

    docker build -t ckan/ckan .

The resulting image contains only CKAN, with a nearly vanilla configuration. In order to use it, you must do one of two things. You can either use the vanilla configuration as-is, and this requires that you specify the location of a Postgres database and a Solr core on startup:

    docker run -i -t -p 80:80 \
      -e DATABASE_URL=postgres://user:pass@hostname/db \
      -e SOLR_URL=http://hostname:8983/solr/ckan_default \
      ckan/ckan

This will run CKAN, connect to the database, and initialise it if need be. Configuring Solr will have to be done separately. There are a couple of other environment variables you can use to customise the deployment, including `ERROR_EMAIL`, which does what you might expect.

Alternatively, and perhaps more realistically you can use this image as a base for extension. If a
configuration file is injected to /etc/ckan/default.ini, the image will use that and ignore the `DATABASE_URL`, `SOLR_URL`, and `ERROR_EMAIL` environment variables.

A minimal Dockerfile that uses this as a base might look something like this:

```Dockerfile
FROM ckan/ckan

ADD ./mycustomconfig.ini /etc/ckan/default.ini
```

Lastly, by default the CKAN file store is at `/var/lib/ckan`, and in a production environment you would almost certainly mount this data volume outside the running container:

    docker run ... -v /mnt/storage:/var/lib/ckan ...

## Why should I care?

I'm of the opinion that deploying CKAN at the moment is too complicated. The package installation makes certain assumptions (Postgres and Solr on the same server; only one CKAN per machine) which seem unrealistically restrictive (not to say unwise) for production environments.

This setup allows you to trivially run multiple CKAN instances on a single machine, all pointing to Postgres and Solr by URL (either local or remote, it doesn't matter), without having to resort to the 10-step source install. It also makes it trivial to use LXC to memory constrain individual instances (`docker -m 1g ...`) which will be important in high-density deployments.

Perhaps more excitingly, this can be used as a binary build base for more complicated deployments, including those which need additional extensions and configuration. You can simply start from this image and add extensions/additional services as necessary. The image builds on [baseimage-docker](https://github.com/phusion/baseimage-docker) which makes running additional supervised services very easy.

## What's not right yet?

1. Perhaps the most important omission from this PR is documentation updates. I'd like to have the discussion with people about whether this is something they want to see in the main CKAN repository before I commit to writing up the docs.
2. CKAN is currently autoconfigured using [some questionable techniques](https://github.com/nickstenning/ckan/blob/04dbaa8e49363154a124470ad690a23769ee6ecb/contrib/docker/svc/ckan/run#L20-L24). Perhaps we should instead permit configuring certain key config properties [using environment variables](http://12factor.net/config)? Perhaps some of what is currently configuration (`site_title`, `site_logo`, `site_description`...) should move into the database?
3. I don't know. You guys know *far* more about what a sensible CKAN deployment does than I do. Tell me what's missing.

## What else should I know?

- I've taken the liberty of reserving the "ckan" username at [the Docker index](https://index.docker.io/u/ckan), so if we want to push this as suggested, to `ckan/ckan` we can.
> postgres and solr configurations default to listen only on loopback (when I installed them at least) so I think we need a discussion of how to listen on the docker interface and how to find out what to use

IIRC (and I can't seem to find it quickly) the Debian policy is that a daemon should, by default, not be open to the world, and should be bound to loopback unless specifically opened up by a config file (etc) change.