Add Time.unix_ns and #to_unix_ns

[garymardell]

I am currently working on an application that requires nanosecond time precision (telemetry data). I receive the number of nanoseconds since the unix epoch. There are already convenience methods when the value is milliseconds (unix_ms and to_unix_ms) however as far as I can tell there is nothing for nanoseconds despite Time supporting the precision.

In my application I have patched in these methods to Time. These methods might be too niche for being included in the standard library though.

[Blacksmoke16]

Resolves #11061

[straight-shoota]

My main concern is that a 64-bit value for nanoseconds can only represent about 300 years +/- the epoch. So it falls short of representing the full range of Time (years 1..9999).
Probably in practice this isn't very relevant. If you're using the unix nanosecond API it's most likely for contemporary timestamps, not far in the future or history.
It would still be nice and easy to remove the limitation on the constructor and allow bigger number types as well. (drop the .to_i).
We could consider changing the return type of #to_unix_ns to Int128 as well, but I'm not sure that makes sense.

[HertzDevil]

This causes an OverflowError for Time.unix_ns(Int64::MIN).to_unix_ns, because nanosecond > 0 implies to_unix * NANOSECONDS_PER_SECOND < Int64::MIN.

This isn't a problem for to_unix_ms because Int64's range far exceeds the representable range of milliseconds (the earliest being Time.unix_ms(-62135596800000)).

[straight-shoota]

@garymardell Would you mind adressing the review comments?
If you don't want to continue with this PR, please let us know and someone else will take over.

[garymardell]

Sorry for the delay, fell off my radar. I have pushed 2 changes:

1. Removed the conversion of nanoseconds to Int64 in .unix_ns as it was unnecessary. This means that it now supports any Int type including Int128 on input allowing the full time range (1...9999 years). Tests were added for the min/max values as Int128.
2. #to_unix_ns now returns an Int128 value, again to support the full range of years.

[straight-shoota]

I think this is the first instance of a Int128 return type in a non-numeric API. But it's probably fine?
That would be my only concern for other reviewers to consider.