Generic templates

This pull request contains extensive changes designed to improve the appearance of our "default" generic site, and allow the appearance to be customized without using TemplateOverrides and other technical knowledge.  It's a Summer of Code project and then some, so it deserves a thorough review.  I'll do my best to implement any improvements needed before the release deadline, but I don't want to rush it, so it would be fine to postpone merging until afterwards if it really isn't ready.

The main goal of this project is to allow us to define "themes" (another name for "generic templates", or maybe "skins") and store them in the code repository.  A theme encapsulates a graphic design for the Web site, including its specialized template overrides, styles, scripts and images. Any of our chapters can then decide which theme they'd like to use, and adjust the parameters of the design, through a Web interface.  Future improvements to the navigational structure of the site will be made by creating/modifying themes targeted to different types of chapters.

More history and details: Vikrant (our talented GSoC student) took up the enormous task of improving our UI and making it easily adjustable.  He didn't finish that (no one could have) but he did improve the default templates and create a "theme editor" for the site.  This editor collects user input on how the site should look (colors, fonts, etc.) and implements them using LESS (parameterized stylesheets) and the Bootstrap library.  Afterwards, I did some refactoring and added a "theme selector" for choosing between different collections of templates and LESS parameterizations.  

The bulk of changes are in a new app, esp.themes.  Theme-related files are copied from the selected directory under esp/esp/themes/theme_data into the live media dirs when a theme is selected; a single CSS file is generated from the theme's specified LESS inputs.  Configuration settings are stored in Tags, but all access should be performed using the ThemeController interface as an abstraction barrier.  Themes can define their own Django form classes to collect additional information from the admins (in addition to the LESS variables collected by the theme editor) if needed.

So far I've created 4 themes to select from, which are in varying stages of readiness; these mimic the current MIT and Chicago site designs, the default templates as Vikrant left them, and an experimental site layout that I developed last year.  I would appreciate feedback on how to fix and improve the themes, but the main challenge is to get a really clean and scalable implementation of the theme infrastructure itself.