The beauty of counter=None on change...

*Background:*
Securesync uses "counter" to determine which records to sync.  The maximum value "counter" sent over the wire becomes the starting counter for the next round-trip of syncing.  

This means that when records are sent over the wire, anything with a lower counter position than what's sent must be sent along with it--otherwise, it will never be requested to be sent in the future.  This logic causes dependencies between models, not just for their ForeignKey values, but for their counter values.

*Issue:*
In both the current version, and develop version of the syncing code, this counter dependency is not taken into account explicitly.  This is problematic.

*Severity:*
Low in the past, high now.  Because UserLogSummary records are sent over the wire before ExerciseLog records, but always have higher counters, this becomes an issue.  In addition, if a Facility or FacilityUser record were ever edited and saved, this could skip unsynced records.  There's some fudge factor, due to "limit" and "boost" in the master code that smooths out some of the issue--but guarantees nothing.

*Changes:*
* Make sure that if a model is going to be sent over the wire, that all models with a lower counter are sent along with it.
* With the new logic to set counters to None, this actually helps avoid this tremendously.  However, if we're sending something over wire with counter=None, then we have to send ALL models with a non-None counter that hasn't been set yet, as updating the None counter to a value would skip over those models.
* To mitigate this, make sure all records that have a deferred counter (Facility*, *Log) have it set to None.  Previously, on create it was NOT set to None, as that value is used for calculating the object's ID.  To solve this, I double-save the record--once to create the ID, once to eliminate the counter.

Concerns:
* If a user upgrades to this code and has not synced, they'll have a HUGE chunk of models that will have to be sent, potentially all at once.  Such large syncs, with unreliable internet connections, can lead to sync never completing, and therefore models never being downloaded.  
    * Future change: instead of sending all models with non-None counters all at once, just set those counters to None.

*Testing:*
* Tested many scenarios, including mixed counter_set and non-counter-set scenarios, including scenarios where models in the past were being skipped (can't send skipped models, but verified that things that would have been skipped in the past are no longer skipped)