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 looks like it will fail intermittently, on slow CI environments there are often pauses/slowdowns that mean a 500ms wait will not be enough. Why do you not want to use waitOnTimeout() ?