IDOC: Securesync sub-modules

This addresses #500.  It was really helpful to separate securesync into 3 sub-modules of varying inter-dependence:
* users - "what" - deals with the data that are synced: Facilities, FacilityGroups, and FacilityUsers.  Mostly about logging in/out, adding, etc.
* devices - "who": deals with the interaction between devices. Things like defining a device, a zone of trust, and which devices belong to which zones.
* engine - "how": this is how the syncing happens.  Includes the methods for syncing, saving, establishing sync sessions, etc.

Along the way, the following changes were made:
* A bit of cruft was removed (unnecessary imports, two "crypto_login" functions that weren't used)
* `ROOT_UUID_NAMESPACE` definition was moved into settings (and made overridable in local_settings)
* `crypto` was refactored into a large, generic part that was put into `utils/crypto.py`, and a small app-specific part that was left in `securesync`.

Along the way, the following workaround were implemented:
* There was one place where interdependence between sub-modules caused import problems: between `securesync.devices.models` and `securesync.engine.models`--specifically the interaction between the Device model and the super class `SyncedModel`.  The design itself is a little weird--`Device` is derived from `SyncedModel`, ... yet the base class uses that `Device`!

I found a way to dynamically import the Device model when needed (on the fly), to avoid that issue.  This seemed fine to me, as again--the classes themselves are a bit odd (though in a way that makes sense).

* In order to define models outside of their regular places, and still be in the `securesync.models` namespace (see #500 for why I wanted to do this), I had to define the `app_name` property on the `Meta` class for each object.  This property, unfortunately, is inherited in subclasses.  That means that all sub-classes of `SyncedModel` now appear in the `securesync` class.

In order to work around this, each subclass of `SyncedModel` that is NOT in the `securesync` module had to define an empty `Meta` class, to clear that property.  Yuck.

I believe the need for this may would disappear when we're able to scrub the imports.  It's not the worst workaround known, but it's less than ideal.

Testing:
* I manually tested most of the distributed server page types, some central server page types, the registration procedure, securesync procedure.  Have not tested the install procedure yet, but will do that today, as part of my code for #198.