Feature: all: avoid Year 2038 issues

Pacemaker has generally serialized time_t values in XML using int, which
creates a Year 2038 problem. This commit uses long long where possible.

Additionally, the result of the time(3) function was not always stored as
time_t. Now, it is, with the exception of the (currently unsigned int) storage
of time values in lrmd_event_data_t, to retain API backward compatibility.
Those should be changed to time_t at the next API breakage. At least they're
unsigned, so they are a year 2106 problem. :-)

This does not ensure that all time differences are also stored as time_t, which
is likely unnecessary but would probably be a good idea.

It is possible there are other uses of epoch time in XML, or storage of epoch
time in something other than time_t, that I didn't catch. The code will need
more thorough investigation.