Simple port of Class2Go's chat feature

Embed a chat widget (much like the calculator widget) into the
courseware. To use, you must point it at an ejabberd box,
configured as `JABBER_DOMAIN` in the settings.
Move Candy.js files to new vendor/ directory
Remove additional jQuery include

jQuery already available across the whole site at the top level, so
no need to include it again specifically for the chat widget.
Test generation of chat settings

Ensure that the chat connection settings are generated properly for
the template context.
Add setting to enable/disable chat site-wide

To protect against chat blowing things up, we include a way to
enable and disable it on an entire site-wide basis.
Use chat settings when deciding whether to render

Only render the chat widget if both the site has enabled it in the
`MITX_FEATURES` and if the course has enabled it. In addition, fail
gracefully with a log warning if the `JABBER_DOMAIN` is not set, and
do not try to render the widget. However, do go ahead and render the
rest of the courseware.
Internationalize open/close chat messages

Per
https://edx-wiki.atlassian.net/wiki/pages/viewpage.action?spaceKey=ENG&title=I18n+coding+guidelines
ensure that chat messages are properly internationalized.
Raise exception if JABBER_DOMAIN not configured

Rather than checking to see if the JABBER_DOMAIN is not set and
continuing on, bail with an ImproperlyConfigured exception as soon
as we notice its absence.
Use ejabberd's MySQL for usernames/passwords

When chat is enabled, sync user accounts with the ejabberd server
by directly writing into its MySQL database. This is ugly in the
sense that ejabberd just does a simple string comparison when
authenticating a password against a username, so we have to send
passwords in the clear in the templates. In a future commit, I'll
implement a password rotation mechanism to make this slightly more
robust: currently, everyone's password is just a dummy string.

To enable this, you'll have to add a 'jabber' key into your
DATABASES dict in the settings, and point at an actual ejabberd's
MySQL instance. The current plan is to just point at one that we've
got set up, since running ejabberd locally (not to mention on
MySQL instead of Mnesia) is non-trivial.
Add utilities to Jabber app to help connecting

Add utilities to the Jabber app to parse the Jabber settings and
build the URLs, chat room names, and user passwords for connecting
to ejabberd. This is a WIP commit since it still needs tests (in
progress...stubbed out with comments).
Use /dev/urandom, not /dev/random

/dev/random blocks if there is not enough entropy to return the
requested number of bytes, and this turns out to hang our AWS
servers. When generating random bytes for Jabber passwords, use
/dev/urandom instead. We figure that this will be "secure enough,"
since we'll have bigger problems if someone manages to get ahold
of our /dev/urandom's seed value.
Remove unused test

Now that the Jabber settings functionality is refactored into its
own Django app, we don't need this test in the Courseware Django
app.
Rename get_password_for_user to get_or_create_...

The new name describes more accurately what the function does: it
creates a new password for the user if it can't find one in the
database.
Move DEFAULT_PASSWORD_LENGTH to JabberUser model

This seems more appropriate as a property of the model as opposed
to a loose constant in the utils module.
Random string generation returns proper length

Before, the length was only accurate if it was a multiple of four.
Now, we calculate the number of bytes needed from /dev/urandom
properly and we truncate the string to just the right length.
(Base64 returns strings that are a multiple of four in length, but
we truncate since we won't ever care to decode the string.)
Adding working utility tests for Jabber app

The majority of the functionality of the Jabber app is in the utils
module, so we test those functions thoroughly.

The test settings don't currently have settings to connect to a
Jabber database (need @jrbl's help to get the migration files to set
it up properly), so we temporarily skip tests that hit the Jabber
users table.
Bring in Jabber settings from json configs
Add migration for Jabber users table for testing

In testing environments, we want to be able to interact with the
database as we create JabberUser instances. This commit adds a
migration for the purposes of testing; the migration should *not*
be used for anything else though. The actual Jabber users table
should be created by ejabberd during provisioning.
Unskip Jabber tests that interact with database

Now that we have a migration for the Jabber users table in the test
environment, we can hook it up in test and "unskip" the tests that
hit that table.
Move Candy.js static assets to Jabber app

Refactor the Candy.js static assets to the Jabber app to keep them
out of the main codebase. This will help modularize the chat widget
so that it's easier to just not include it by default, if desired.