Draft: Use native timegm when available.

Continue having a tor_gmtime_impl() unit test so that we can detect any problems in our replacement function; add a new test function to make sure that gmtime<->timegm are a round-trip on now-ish times.

This is a fix for bug #40383 (closed), wherein we ran into trouble because tor_timegm() does not believe that time_t should include a count of leap seconds, but FreeBSD's gmtime believes that it should. This disagreement meant that for a certain amount of time each day, instead of calculating the most recent midnight, our voting-schedule functions would calculate the second-most-recent midnight, and lead to an assertion failure.

I am calling this a bugfix on 0.2.0.3-alpha when we first started calculating our voting schedule in this way.

Let's merge this first in 0.4.7 and consider a backport after a while if nothing breaks. If some OS someplace has a broken timegm immplementation, then this patch will break things there.