subsec_{milli,micro,nano}seconds may have over-inclusive documented ranges

[samcowger]

Documentation of these functions promises that they will produce values in the ranges -1_000..1_000, -1_000_000..1_000_000, and -1_000_000_000..1_000_000_000, respectively, but I don't see how they could produce the lowest value in their stated bounds.

In terms of code, I'll use subsec_nanoseconds as an example:

time/time/src/duration.rs

Lines 912 to 923 in 7a6a800

	/// Get the number of nanoseconds past the number of whole seconds.
	///
	/// The returned value will always be in the range `-1_000_000_000..1_000_000_000`.
	///
	/// ```rust
	/// # use time::ext::NumericalDuration;
	/// assert_eq!(1.000_000_400.seconds().subsec_nanoseconds(), 400);
	/// assert_eq!((-1.000_000_400).seconds().subsec_nanoseconds(), -400);
	/// ```
	pub const fn subsec_nanoseconds(self) -> i32 {
	self.nanoseconds.get()
	}

self.nanoseconds is a Nanoseconds, which is a RangedI32 - in particular, a RangedI32<{ -(Nanosecond::per(Second) as i32 - 1) }, { Nanosecond::per(Second) as i32 - 1 }>. per seems to be defined appropriately, so this gives us RangedI32<-999_999_999, 999_999_999>. Given that a RangedI32<MIN, MAX> promises to contain "[a]n i32 that is known to be in the range MIN..=MAX", it's impossible for -1_000_000_000 to inhabit Nanoseconds, and so to be produced by subsec_nanoseconds.

I believe the same logic can be extended to subsec_microseconds and subsec_milliseconds, since they defer to subsec_nanoseconds.

[jhpratt]

Yeah, this is a mistake. It should be changed to -999_999_999..=999_999_999, using the same number for both bounds for symmetry. Likewise for other similar values.