Microsites

@chrisndodge has submitted pull request #2061 for the microsites feature, which is apparently on a tight deadline to be merged by Monday. I took a look at that pull request, and I have several concerns about the architecture of that solution. Since Chris has been crazy busy lately, I decided to create a new branch, working off of his, to try to show what I believe to be a better architecture. The main differences are:

* #2061 creates a new middleware (common/djangoapps/microsite_configuration/middleware.py) that runs at the start and end of every single request, whether the request is for a page that would be modified by the presence of a microsite or not. This pull request replaces that middleware with a set of functions (common/djangoapps/student/microsites.py) that are called wherever microsite information is necessary, so there are some requests that don't ever call it.

* Because the middleware ran at the start and end of every request, it was possible to set information on and read information from the MicrositeConfiguration object at any time -- and #2061 takes full advantage of that, treating it as a global variable. It was very difficult to trace where the information on that object comes from, where it is modified, and so on. By contrast, because there is no global object in this PR, it's easier to trace the logic of where the microsite information comes from.

* #2061 defines an `enable_microsites()` function in a settings file, which must be run after all of the microsite logic is defined in that same file -- which makes it almost impossible to cleanly change or reorder the microsite settings without also looking at every single place where that function is called. This PR moves that function into `lms/startup.py`, which is called *after* all the settings logic is completed, so that we don't need to worry about ordering of the settings.

* #2061 has a very verbose, layered API: a `MicrositeConfiguration` object with a `get_microsite_configuration_value()` class method, that wraps a Python dict. I've removed this API entirely, so that the Python dict is available, with stardard indexing and `get()` syntax, which is much more familiar, concise, and readable.

* #2061 defines the microsite settings as a dictionary of key-value pairs, where the key is the name of a directory on disk, and the value is another dict that has configuration information for the microsite. My PR is similar, but rather than the key being the name of a directory, it is the subdomain where the microsite is available: that way, you can't define overlapping microsite subdomains, and you *can* define two domains that point to the same microsite (like mit.edx.org and mitx.edx.org).

Unfortunately, I haven't been able to test this at all, because I haven't gotten the microsite assets that Chris has been using to test his branch. However, I believe the code is more concise, more readable, and more maintainable, and I'd like to at least have other developers compare the the two pull requests, so that whatever goes in has a decent code review.