Historically, the library evolved using "a Long of milliseconds"
as the standard of denoting durations.
Since then, `kotlin.time.Duration` appeared, encompassing a number
of useful conversions.

There are several consequences to this change.
- Before, `delay(Long)` and `delay(Duration)` were not easily
  expressed via one another.
  For example, `delay(Long.MAX_VALUE / 2 + 1)`
  (up until `Long.MAX_VALUE`) used to be considered a valid
  delay, but it was not expressible in `delay(Duration)`.
  Therefore, `delay(Long)` was the more fundamental implementation.
  However, `delay(Duration)` could not just be expressed as
  `delay(inWholeMilliseconds)`, as we need to round the durations
  up when delaying events, and this required complex logic.
  With this change, `delay(Duration)` is taken as the standard
  implementation, and `delay(Long)` is just
  `delay(timeMillis.milliseconds)`, simplifying the conceptual
  space.
- The same goes for other APIs accepting either a duration or
  some Long number of milliseconds.
- In several platform APIs, we are actually able to
  pass nanoseconds as the duration to wait for.
  We can now accurately do that. This precision is unlikely to
  be important in practice, but it is still nice that we are
  not losing any information in transit.
- On Android's main thread, it's no longer possible to wait for
  `Long.MAX_VALUE / 2` milliseconds: it's considered an infinite
  duration.
  `Long.MAX_VALUE / 2 - 1` is still fine.
- In `kotlinx-coroutines-test`, before, it was possible to
  observe correct behavior for up to `Long.MAX_VALUE` milliseconds.
  Now, this value is drastically reduced, to be able to test
  the nanosecond precision.
- In `kotlinx-coroutines-test`, we now fail with
  an `IllegalStateException` if we enter the
  representable ceiling of time during the test.
  Before, we used to continue the test execution, only using the
  order in which tasks arrived but not their virtual time values.