Move unload handling to a separate method

Instead of calling setCookie() directly on the unload handler, move it
to a separate unload handler method where we can do more stuff if
needed... like fire an unload beacon, for example.
setCookie on click as well

It's possible for users to open links in a tab.  In this case the new
tab's onload event will fire, but the unload event for the current tab
doesn't fire (since there's no unload).  We still need to capture the
time the user initiated the action, which is most likely the click
event.

Note that since we use onmouseup to trap click events, this will not
fire on keyboard initiated links.  On MacOSX, you can open links in a
new window using Shift+Enter and new tab using Cmd+Enter (Alt+Enter
downloads).  It's still better than nothing.
Merge branch 'master' into gh-pages
pass event object to unload handler
Add other times to cookie based on how it was set

The cookie can be set from an unload handler, a page hide handler or a
click handler.  We should be able to store all of these in the cookie to
figure out the most interesting time when we read the cookie.
Merge branch 'master' into gh-pages
change order of params
Allow both unload and pagehide to fire

Just as an experiment to see if unload and pagehide times are different
on Safari
Merge branch 'master' into gh-pages
Pick one of pagehide and unload

pagehide and onload fire at the same time, so pick just one of them.
pagehide works well with the PageCache on Safari, so prefer that
over onload
start time is one of unload or click time

We set the unload time and the click time in the cookie, and when
use the best one as the load start time.  unload is preferred,
click is used if it's unavailable (Opera only)
Approximate fb time from on unload/pagehide

First byte time is about 1ms off from when the unload or pagehide
event fires.  This is so because browsers do not unload a page from
the browser window until they have something to display from the new
page.  This gives us a good approximation of the first byte time
since that's when browser have something to start doing.
Merge branch 'master' into gh-pages
Get data from cookie when getting from navtiming

It turns out that in-page JavaScript does not execute on Safari
when using the Back-Forward buttons.  This has to do with the page
state being stored in the PageCache.  To get around this, we need
to recheck the cookie every time we need a start time.

We also need to reset t_start and t_fb_approx to undefined if the
cookie's values were inconclusive.  It's important that the order
of calls to initFromCookie and initNavTiming be such since
initNavTiming will always have the correct time if navtiming is
available.
Add msFirstPaint time to nt_first_paint

We now also collect first paint time on IE9 and above.  However, note
the inconsistency between IE and Chrome.  IE reports first paint time in
milliseconds since the epoch.  This is consistent with all the other
navtiming timers.  Chrome reports it in seconds.microseconds, which is
inconsistent.

Receivers will have to determine if this was in seconds or in
milliseconds and convert accordingly.  Since data range is very
different, this should not be a problem.
Merge branch 'master' into gh-pages
empty site_domain will disable cookies
Merge branch 'master' into gh-pages