Include a Django project with ICEkit.

[mrmachine]

With this change, we can make ICEkit more like an off the shelf CMS that can be installed and used immediately in its default configuration.

Currently, it is more like a library that must be installed into a new or existing Django project, and we have a separate project template that we use to create new ICEkit projects.

Important things to note:

• We can run ICEkit via Docker or directly, with or without a Django project. This should make it easier to develop ICEkit itself. Just clone the repository, make changes and run it to test your changes.
• Settings and other boilerplate code from ixc-project-template (e.g. celery.py, context_processors.py, jinja2.py, urls.py, wsgi.py, etc.) have been added to icekit.project. This is the Django project ICEkit will use by default.
• There is no need to juggle a project template that is not immediately useful (without being rendered as a new project) and an code library that must be installed into a new/temporary project to test.
• ICEkit now includes its own project template (and a startproject.sh script to render it) that is much simpler than ixc-project-template and includes much less boilerplate code (most of which is now part of ICEkit).
  • Hooks for Bower components, Node modules, Python requirements, settings, static files, and templates, to override and extend ICEkit defaults.
  • Files that configure Docker to build and run an image and run the project. The image is built on top of an official ICEkit image, which makes build time much faster because the ICEkit image already contains everything except project overrides via the hooks above.
  • A go.sh entrypoint script that makes running directly work similarly to when running via Docker. Database name is derived from the project directory name and git branch. Bower components, Node modules and Python requirements are updated automatically. Migrations are applied automatically.
• When running with Docker, we now run celery (worker, beat, flower) in separate containers for independent scaling. Since these all use the same image, which tries to apply outdated migrations at startup, we now use Redis locks to ensure that only one container executes such code at the same time.
• ICEkit can still be used as a library, just as it is today. Existing projects don't need to change anything. But they could be updated to inherit from ICEkit's base settings instead of duplicating ~700 hundred lines of settings and other boilerplate code from the project template, to reduce future divergence.
• We now have a Deploy to Docker Cloud button in the README. You won't be able to customise your project when deploying the official ICEkit Docker image this way, but you can easily get a site wit the default ICEkit configuration and styling.
• Tests still pass for django17-py27, but this and other Django 1.7 environments are no longer tested automatically.
• We were only using django-generic for one thing, to add SITE_NAME to the context for RequestContext objects. Since django-generic isn't on PyPI and I wasn't sure that we should put it on there (it's a fork of DrMeers repo), I removed it instead.
• I have added a very basic intro page (fallback when DEBUG=True and when no Fluent pages exist).

Follow the instructions in README.md and docs/contributing.md to get started.

[coveralls]

Changes Unknown when pulling 66b4dd0 on feature/project into * on develop*.

[coveralls]

Changes Unknown when pulling 8822ca9 on feature/project into * on develop*.

[coveralls]

Changes Unknown when pulling e7c3190 on feature/project into * on develop*.

[coveralls]

Changes Unknown when pulling e7c3190 on feature/project into * on develop*.

[coveralls]

Changes Unknown when pulling 8d01048 on feature/project into * on develop*.