timecode problem with FCP XML converter

## Bug Report

### Incorrect Functionality and General Questions

We used `otioconvert` on a FCP file with content described as:
```

24
TRUE

```
and got an output OTIO file with a bunch of
```
"rate": 23.976023976023979
```
entries. So far so good. However, `otiostat` is unhappy with the resulting file:
```
parsed: True
top level object: Timeline.1
number of tracks: 3
Tracks are the same length: True
deepest nesting: 4
number of clips: 6
total duration: RationalTime(33820, 23.976)
There was a system error: invalid timecode rate
top level rate: 23.97602397602398
clips with cdl data: 0
Tracks with non standard types: 0
```

## To Reproduce

1. CentOS Linux release 7.2.1511 (Core)
2. Python 3.6.8
3. n/a
4. OpenTimelineIO 0.13.0 (via pip install)
5.
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)
```

## Expected Behavior

Well, I would expect that `otiostat` would be happy with `otioconvert`'s output. That said, I don't know if `otioconvert` emits an incorrect decimal place, if `otiostat` needs to change its `_top_level_rate` behavior (note both the 23.976 and 23.97602397602398 strings in its output), or even if there need to be additional entries in the `valid_timecode_rates` array.

## Screenshots

n/a

## Logs

n/a

## Additional Context

Interestingly enough, I get this on the same machine:
```
Python 3.6.8 (default, Apr 2 2020, 13:34:55)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> float(24) * (1000.0 / 1001)
23.976023976023978
>>> str(float(24) * (1000.0 / 1001))
'23.976023976023978'
```
As such, I'm not sure why `otioconvert` writes a least significant digit of 9 instead of 8.

Reproduce the reported FCP XML conversion with otioconvert, then inspect the resulting rate values with otiostat. Read the _top_level_rate behavior and valid_timecode_rates handling mentioned in the report, and compare the converter's emitted rate with the validator's accepted rates. Done means otiostat accepts the file produced by otioconvert without an invalid timecode rate error.

Written by the indexing model from the issue text.