WFLY-3630: Fixes for Timer testcase and Timer impl.

triggering a timer caused an increment of the nextExpiration, although nextExpiration already is in the future.
Depending on the power of the test machine and granularity of System.currentTimeMillis sometimes calculateNextTimeout came out with the same time, because periods resulted to -1. This made the testcase fail then on my Windows system sometimes and never on my much slower Unix testsystem.

The relevant changes are in methods calculateNextTimeout in CalendarTimerTask and TimerTask.
If nextExpiration is greater than now, return nextExpiration as it is.
For calendarTimer I got 2 Task for the same timer for the same expiration time then. To avoid it, I added the oldTask.cancel().

Old other changes cosmetic or elimination of dead code.
I don't think this is correct. If there is a granularity issue I think that we calculating the next timeout we should just add one to the value of currentTimeMillis(), to make sure that a new timeout is calculated.