Bug 851262 - [email/IMAP] Bisection grow timezone logic generating zero-delta syncs that explode on gmail rs=squib

This is squashed; here are the notable commit messages:

:squib brought up a good point that it wasn't clear why I wasn't adding
the timezone offset to the limit.  Which caused me to realize that when
dealing with NOW(), we indeed should be applying the timezone offset
since our accuracy ranges are all centered around the local timezone of
the server.

Additional timezone fixes relating to NOW():

The previous commit did not go far enough.  Specifically, all uses of NOW()
turned out to be suspect and needing to be fixed where it dealt with accuracy
ranges or talking with the server.  This also entailed fixing makeDaysAgo to
take the timezone offset, plus makeDaysBefore for when the date is null and
it ends up calling makeDaysAgo.

It was particularly important to calculate our effective end TS with the
timezone offset for our bisection calculation.  Otherwise, we ended up with the
same bisection loop on 2 days.

The other change is that when growing in the FUTUREWARDS direction, we also
want to observe the highest legal endTS there too.  We only differ in how we
calculate the initial endTS, but we still don't want to name a date that's
still in the relative future as our accuracy range, by definition, can't
include it.
Merge pull request #148 from asutherland/growth-refresh-1-day

Bug 851262 - [email/IMAP] Bisection grow timezone logic generating zero-delta syncs that explode on gmail. rs=squib