Avoiding large decimal places / int overflow for CMTime <-> RationalTime conversion

[vade]

We ideally want to find some lowest common denominators for our time conversion

Some observations so far

• Integer rates work pretty well
• non int rates, like in rates in the OpenTImelineIO Swift Bindings unit tests 23.976 for example are typically represented as something like 24000/1001 rates in CMTime
• Our current strategy is instead to represent it at 23976 - which is fine, until we hit values very large
• We also have issues where rate is 1.0, and value is has many many decimal places, like 72.1239898271647162 which shows up some times (see RationalTime.fromSeconds() for example)
• To try to resolve this, I try to use the minFrameDuration to renormalize times to avoid rounding issues
• A side effect of this, is for some poorly encoded media, minFrameDuration has wonky values

In short, our timing conversion isnt perfect

Things to try

• Make a list of common frame rates (perhaps leverage TimeCodeKit) and find best fit ratios that are the smallest int denominator
• See if naturalTimeScale is a better replacement for minFrameDuration to help with the best units for CMTime denominators.

[vade]

If we use our custom layer instructions in Beta 1 (currently commented out) - we get a video composition validation error with some sample media from Davinci Resolve, which has incredibly tiny taps likely due to numerical precision issues from converting RationalTime to CMTime :

See this thread on OTIO TSC Slack

(lldb) po timeRange.start.seconds
18.977291665
(lldb) po timeRange.end.seconds
18.977291666