Implement record "deletion" (deletion stub++)

This is a moderately risky PR; the purposes to post here are:

* To get feedback on the design and direction
* To encourage the development of automated sync tests
* To show that this isn't that hard--this is 5 hours of work.

So, right now lots of things are held up because we don't allow data deletion.  We have a bunch of crappy data, people aren't satisfied with their data displays (because it has a bunch of undeletable test data), and overall things are rigid.  Of all the feedback we get, asking about deleting objects is one of the most frequent.

I've implemented data "deletions" in the following way:

* Deleted data exist as before--just with the `deleted` field set to `True`
* The default `manager` for querying out data simply filters out objects with `deleted=True`
* A secondary `manager`, used for syncing purposes, doesn't contain that filter.
* When an objects is "deleted", all objects using it as a foreign key are also "deleted" (just like Django does).
* I disabled the **actual** delete functionality, just for kicks (and because we don't define system state if this actually happens!).  
* I provide back-door entry hooks (via `settings`) for showing "deleted" data and ACTUALLY deleting objects.

The best thing about this implementation (in my eyes) is that while the data are not deleted... programmatically, it all works as if they are.   Queries will not return them.  So, for example, if we started preventing multiple facilities with the same name on the same zone, there would be no conflict between a new facility and a "deleted" facility with the same name--a query on that name would show no results.

The Python tips and tricks to do this also allowed me to remove the `add_syncing_models` call at the bottom of each `models.py` file, instead automatically any `SyncedModel` subclass to the list of syncing models.  Now we're talking!

Testing:

* Right now our distributed server interface only enables deleting `Facility` objects.  So, I created facilities, ran `generaterealdata`, etc. to see that I could delete through the interface
* I tested through `shell_plus` to check that **actual** deletion throws an error.
* I ran syncing tests.  Since `deleted` is a field that triggers syncing (nice job @jamalex!), both deleted and non-deleted objects sync.

Notes:

* This isn't a deletion stub, nor am I convinced that we ever want one.  These are full records--just a method to hide them.  That way, deletion is reversible, and good data that others may want to delete we can use for our own purposes (whatever they may be).