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.
This is not because of granularity of currentTimeMillis. There's a similar change in TimerTask.
Valid for both kinds:
Test case creates a new Timer at t0 with timeout in t0 + 3000 ms.
Immediately after that (t0 + few ms) the trigger of the timer is called.
What should be the next expiration of the timer afterwards?
With my changes it's still t0 + 3000 ms, because this next timeout is in the future.
Without the change nextExpiration will be incremented to (t0 + 3000 ms) + 3000 ms, so the former scheduled timeout at t0 + 3000 ms does not take part. --> Test case has to be changed accordingly.
Or, 3rd option: should nextExpiration be time of triggering + increment / calculation, resulting to t0 + few ms + 3000 ms for the IntervalTimer respective calculated nextSchedule based on t0 + few ms for CalendarTimer?
--> Test case has to be changed accordingly.