Fix time arithmetic in Validations and Consensus

[carlhua]

Several spots in generic validation and consensus do arithmetic on times/durations to see if messages are stale. Since NetClock uses uint32_t for its representation, we should be careful to avoid the potential for overflow. In most cases, this means using addition rather than subtraction, e.g.

signed > now - early 

to

signed + early > now

Exported from RIPD-1489

[HowardHinnant]

To address this issue a comprehensive survey of all uses of NetClock::time_point in rippled was made. Only two minor were found.

1. src/ripple/consensus/Validations.h has this expression:

signTime > (now - p.validationCURRENT_EARLY)

This is the expression refered to as being vulnerable to unsigned overflow. However it turns out this expression is fine because p.validationCURRENT_EARLY is a 64 bit signed integral type. Thus the 32 but unsigned now is losslessly converted to signed 64 bit prior to the conversion. Additionally the 32 but unsigned signTime is converted to signed 64 bit prior to the comparison.

The expression is correct and bullet-proof as is. A comment to this effect has been added.

2. src/ripple/app/tx/impl/CreateOffer.cpp has this expression:

NetClock::time_point const when{ctx_.view().parentCloseTime()};

While correct, using explicit conversion syntax for implicit construction is error-prone because one might accidentally choose an unwanted explicit constructor. This code is safer using implicit syntax to ensure that only an implicit constructor is chosen:

NetClock::time_point const when = ctx_.view().parentCloseTime();