bug#18176: 24.4.50; Errors on dates far in the future in url.el

[Paul Eggert <eggert@cs.ucla.edu>]

That "4038" started out as a "2038" (the year 32-bit signed time_t's 
will roll around) and then someone added 2000 seemingly at random.  We 
might as well bump it to most-positive-fixnum.

However, this won't work on hosts with 32-bit time_t, because the 
low-level primitives can't go past 2038.  (Even on 64-bit hosts it won't 
work for time stamps in the very far future.)  So url-cookie-expired-p 
needs to take greater care here.

Fixing this uncovered a couple of other problems.  First, date-to-time 
shouldn't fall back on timezone-make-date-arpa-standard if encode-time 
says the date is out of range.  Second, the low-level primitives don't 
consistently call time_overflow when there's a time overflow.

This particular use case suggests that url-cookie-expired-p should treat 
out-of-range expiration dates as being infinite.

I installed a patch to do all the above, as trunk bzr 117637.  I suppose 
we could get fancier by distinguishing negative from positive time 
overflow, and/or by creating error symbols for time overflow flavors, 
but this patch should be enough to fix the current bug.