Add travis config to fix failing tests
Merge pull request #4 from lestard/0.x

Fixes #3 and the "Gtk-WARNING **: cannot open display" errors on on
Travis CI that it was likely referring to.

* lestard/0.x:
  Add travis config to fix failing tests
Handle negative delay times

Prior to this commit, `JavaFxScheduler` asserted that delay time values
must non-negative and less than `Integer.MAX_VALUE` for compatibility
with the JavaFX timer. This resulted in the possibility of false negative
test failures for `JavaFxSchedulerTest#testPeriodicScheduling`, because
when the system is under load (e.g. when CPUs are maxed out), negative
delay time values get passed to `#schedule`. These negative values are
perfectly valid, indicating no delay (and are documented as such--see
`Worker#schedule` Javadoc).

This commit removes the assertion of non-negative values, and instead
simply adapts any negative value to zero, which keeps the JavaFX timing
infrastructure happy. It also removes the upper boundary of
`Integer.MAX_VALUE` for delay times, as it does not appear that JavaFX
actually imposes any such limitation.

JavaFxSchedulerTest#testInvalidDelayValues has been removed entirely, as
there is essentially no such thing as an "invalid delay value" at this
point.

All remaining tests now typically succeed save for very infrequent
failures of `JavaFxSchedulerTest#testNestedActions`. The reason for these
non-deterministic failures is as yet unknown, but because they appear to
be unrelated to the changes addressed in this commit, no attempt is made
here to diagnose and fix them.

Note that this branch includes @lestard's pull request #4, which will
indeed be necessary to fix "display not found" errors under Travis CI's
headless environment. i.e. if that commit isn't included, this changes
in this commit won't have a chance of succeeding.
Increase task completion timeout from 0.5 => 1.0 sec

As seen at https://travis-ci.org/ReactiveX/RxJavaFX/builds/41017012,
`JavaFxSchedulerTest.testPeriodicScheduling` still fails under Travis
CI, though it is assumed not because of negative delay time values but
because of actual failure to execute tasks in the given half-second
period. This failure is unreproducible on a 4-core MBP, so the 1 second
timeout is a guess.
Merge pull request #5 from cbeams/handle-negative-delays

Handle negative delay times