Update prepared statement DB backend for Django 1.4
Update auth middleware for Django 1.4

WARNING: This is a hack to code I don't fully understand yet and it is not
well tested.  Further review is necessary.

Django made some changes to its internal APIs for the authentication
middleware.  This broke our customized authentication middleware.
We had a substantial amount of code replacing the Django auth middleware's
request.user object with an ESPUser.  It looks like Django's new lazy
evaluation class will work here.

We may want to restore the part that tries to set request.user when
Django's get_user function doesn't think anyone is logged in, but the user
ID is stored in the session.  I have no idea why this would happen though.

One other thing I changed is to import ESPUser.  This hasn't broken
anything for me, but I bet there was a reason the previous code tiptoed
around importing ESPUser until it was actually necessary, so I would be
cautious here.
Update cache_inclusion_tag to work with Django 1.4

Django's internal APIs for template tags changed.  This attempts to deal
with that by modeling the cache_inclusion_tag's tag generator on some of
Django's tags.

Appears to work for our QSD and catalog tags, but may be broken elsewhere.
Converts the AdminVitals section of the dashboard to the new-style
management look

This breaks down the AdminVitals sections into related sections, and
puts them in expandable sections, so that they take up less space
initially. This will ultimately load each component of the AdminVitals
individually via AJAX when they are expanded.
Merge branch 'main' into ajaxify_dashboard
Partially ajaxifies the list of classes
Finishes AJAXifying the dashboard AdminClass inline template
Adds in the stats JSON view, which is heavily based on the AdminVital prepare function
Implements an AJAXified AdminVitals module, which uses the stats JSON view
Fixes up the caching on the stats function -- dashboard is now fast
Fixes the 'use_rapid_approval' tag in AdminClass
Fixes a slight bug in the 'use_rapid_approval' Tag checking
Set dashboard styling with rapid approval correctly
Makes a few tweaks to rapid approval.

There was a problem with the popup status not getting updated. I
modified the caching of the class_info function slightly. This
didn't actually fix it, since it turns out the problem was with
browser caching, but the change makes sense to keep in I think.

I also modified wording to be unified (chose "Approved" over
"Accepted" in all locations).
Fix bug where there is an extra slash after the host URL
Merge remote-tracking branch 'origin/django-1.4-support' into main
Make class documents show up in catalog preview.

This way, teachers who try to add class documents don't get confused
when said class documents don't show up in the preview.

ClassSubject.objects.catalog is kind of magical and selects a bunch of
related data in one giant query. Our catalog-rendering code assumes
the presence of said data, so wherever we invoke it we should pass it
classes fetched via ClassSubject.objects.catalog.

We could use catalog_cached instead of catalog since correctness of
student counts (if they even appear) isn't important in the catalog
preview. However, the performance hit is tiny since few people even
look at catalog previews--and whatever comes out of render_class_core
*needs* to be correct because that will be cached and reused in the
actual catalog.

(Said observation about caching also implies that student confusion is
a relevant motivation for this fix.)
Make render_class_core depend on qsdmedia.Media.

This is in case teachers upload class documents and then immediately
check the catalog preview to see whether they show up.

Some remarks to the future:

1. This will likely require adjustment when the schema simplification
   project gets merged.

2. Using depend_on_row instead of depend_on_model implies we won't
   catch when a document moves from one class to another. However, I'd
   bet that almost never happens; and I think it's worth not having to
   regenerate the whole catalog every time a teacher uploads a file.

3. This silently fails to empty the right cache if it hits a DataTree
   node with more than one ClassSubject on it. I suspect such DataTree
   errors have enough other symptoms that we can pretend they never
   happen. Also, in a few months, remark 1 will make this irrelevant.
Merges in main branch
Merges listclasses.html