HPCC-8572 Std.Date functionality

Time support added to Std.Date; new timelib plugin; stringlib modifications to support time; updated tests for new Std.Date functionality.
I ran into a bizarre problem with that.  One (and only one) ASSERT in my tests failed.  It appeared that the conversion between INTEGER2 and int (four byte signed int, right?) was leaving garbage in the int, which produced an incorrect answer.  The assert was:

ASSERT(Date.AdjustDate(20000229, year_delta:=-1) = 19990301);

What the code was emitting was (approximate) 653170301 instead.  (The year bit was close to 65535, but not quite; I don't remember exactly).  Explicitly shortening the argument to a short fixed that problem.  Is there a better way?  Should the ECL use INTEGER4 instead and then we use int types in the C++ code?  I was trying to avoid a case where some ECL programmer tried to adjust a date by 2^32-1 years...