Local # of iterations for hashing passwords

This is a first pass at trying to address #603.  This needs benchmarking; @gimick tried taking a look today, but things weren't quite up to speed.

Background:
One way to combat brute-force password hacking is to simply force the password verification algorithm to be intentionally inefficient.  This limits the # of attempts / s a brute force system could try.  However, these inefficiencies are forced upon the real auth system at login time.  @gimick has found this to be a bottleneck for us on the Raspberry Pi

Changes:
* Create a local (non-synced) table that contains lower-iterated password hashes for users.
* When a user logs in, we try to find their password first in this lower-iterated cache, then the "normal" (synced) password hash.
* We add hashes to this cache table when a user is created, when they log in, or when they set their password.
* A cache entry can be invalidated if the current # of hashes (per a setting) doesn't match what was stored in that cache item.
* Must be enabled by entering `PASSWORD_ITERATIONS_TEACHER` and/or `PASSWORD_ITERATIONS_STUDENT`

Notes:
* I wanted to use the Django post-save notification, but I didn't have access to the password in any nice way.  So I entered the code in the FacilityUser auth methods directly.  This means that if passwords are changed outside of calling set_password, the cache can get out of sync.
* There's one "guess" on password structure in the code--will ask @jamalex to look.

Testing:
* Tested on adding new user, logging in as user with and without a password cache item, changing password via management command.