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.
It fails intermittently right now, before the change.
Because of "waitOverTimer" the timer is suspended for timerInterval + 1000ms.
So timer's nextExpiration is ~1000ms in the past when activated. Therefore Activation creates a timer for immediate execution and 3000ms interval. Not yet fired.
But now the proceeding of the test case and the timer task work in parallel.
Sleeping some time in the test case makes sure, that the timer fires first before the timerTicks is retrieved and compared to 2.
When waitOnTimeout the reactivated timer may have fired or not and we would get 2 or 3 afterwards, again an unpredictable result.
The number of ms must be between 0 and 3000ms (the interval), not too close to the borders of the interval. I have a slow machine (SPARC III @ 1,2GHz) and this time span was more than enough.