Adds template blocks to elements/html

Some pages (such as the custom form creation page, and other pages that
make heavy use of Javascript and particular Javascript libraries) only
want to import certain subsets of our usual Javascript library imports,
or want to use different versions of jQuery or Dojo. This commit adds
some new blocks to the base elements/html template, that way developers
can fine-tune the Javascript libraries that they import, without having
to re-write most of the library imports or abandoning the use of
elements/html altogether.

This commit also adds template blocks for the HTML DOCTYPE and the body
class, so that developers can override these fields as well.
Fixes customform templates to import jQuery once

Makes use of the new blocks in the elements/html template in order to
override the version of jQuery that is imported and binded to $j.

In the case of customforms/form_base.html and
media/scripts/customforms-validation.js, this change correctly loads
two different versions of jQuery, and binds them to distinct variables.
The usual jQuery version is, as always, bound to $j, whereas the
version that customforms uses is bound to $jcf.
Extends 2 customform templates from elements/html

customforms/index.html and customforms/view_results.html were
previously not extending elements/html. This meant that they weren't
using the CSRF init code or binding jQuery to $j like the rest of the
site, amongst possibly other issues. This commit changes those
templates to inherit from elements/html, and changes the custom
javascript code they include to reference jQuery via the $j variable.
Cleans up some code

Comments some Javascript console debugging code, removes some
commented, unused Javascript, and removes a test file.
Adds more permission checks for customforms views

Additionally, for the views that already had permission checks, changes
them to use a decorator, that way we only have to change one function
if we decide to apply different permissions in the future.
Adds FileFields to customforms

This code includes an arguably important TODO. Since the current
version of the Django FormWizard only allows FileFields on the last
page of a multi-page form, technically this code allows the user to
create a seamingly-valid customform that will actually cause Django to
raise an Exception upon its rendering. For now, since the only custom
forms I've ever seen used are one page, this shouldn't be an issue. But
I want to come back to this in the future, when I have more time, and
write code that will prevent this from happening.
Update customforms with FormWizard from Django 1.4

The FormWizard from Django 1.3 is unable to accommodate File Fields on
all but the last step of the form. The one in Django 1.4 allows us to
insert File Fields into all steps of the form. This commit plugs in
the new FormWizard as an app and updates the customforms code to play
nicely with it. This should hold until the codebase is updated to Django
1.4.

The app must be installed using: pip install django-formwizard.
Get FileFields to work in customforms

FileFields should now work in customforms, and can be added at any step
of the form. Between steps, uploaded files are temporarily stored
server-side using the FileSystemStorage class. Once the entire form
is validated, files are stored in the directory:
/media/uploaded/Response_[form_id]
Fix jQuery name typo ($ -> $j) in custom_form.js
Merge branch 'jmoldow_customforms_additions' into customforms_formwizard_changes

Conflicts:
	esp/esp/customforms/DynamicForm.py
	esp/esp/customforms/DynamicModel.py
	esp/public/media/scripts/custom_form.js
	esp/public/media/scripts/customforms_response.js
	esp/templates/customforms/form.html
Fix a couple of customforms typos
Add django-formwizard to dependencies
Merge branch 'customforms_formwizard_changes' into main
Use Django global settings in DynamicModel.py