AAF of Media Composer transcoded clip returns inaccurate timecode

I have a Media Composer 2018.2 generated [AAF](https://github.com/PixarAnimationStudios/OpenTimelineIO/files/6529975/linked_xcoded_SingleClip_03000200.zip) containing a single 23.976 sequence with a single 23.976 video clip. The clip was originally AMA linked and then transcoded to DNxHD which is a common media ingest practice in Media Composer.

The source clip's starting SMPTE timecode is 03:00:02:00. Represented as a single event EDL the sequence looks like:

`001 03000200_2398 V C 03:00:02:00 03:00:07:00 01:00:00:00 01:00:05:00 `

In OTIO: `trimmed_range().start_time`

Returns:
`RationalTime(0, 23.976)`

It should return:
`RationalTime(259248, 23.976)`

This is consistent across Linux, macOS, and Windows in Python 2.7 and 3.8.6.

However, if I import the clip to Media Composer instead of linking and transcoding and export a new AAF, the OTIO reports the correct start_time.

When I conform the original AAF in Media Composer or DaVinci Resolve the source clips shows the correct 03:00:02:00 start time.

I have looked inside the AAF using the [model browser](https://github.com/markreidvfx/pyaaf2/blob/master/examples/qt_aafmodel.py). From reading the AAF spec I think I understand that timecode start times use an offset, but I can not find a single offset or any other integer value that would correspond to an offset of 3 hours and 2 seconds at 23.976. Obviously Resolve is reading or calculating this value from something in the same AAF file, but either I can't see it in the AAF model or AAF2 is not reading all the objects stored in the file.

This issue may be possibly related to [#523](https://github.com/PixarAnimationStudios/OpenTimelineIO/issues/523#issue-451340708), but transcoded clips have no Tape Name in the first place. When I assign a Tape Name to this clip in Media Composer the start_time remains unchanged.

I have tried this [multiple timecode solution](https://github.com/stefanschulze/OpenTimelineIO/blob/f17903fc385163a7efb7a836ea8188e3e78f4a80/contrib/opentimelineio_contrib/adapters/advanced_authoring_format.py) from @stefanschulze, but in my case there is no exception in the first place.

Reproduce the supplied AAF import and inspect trimmed_range().start_time. Read the pyaaf2 model-browser example and contrib/opentimelineio_contrib/adapters/advanced_authoring_format.py, then compare with issue #523. Done means the imported clip reports RationalTime(259248, 23.976) while the alternate correct-import case remains correct.

Written by the indexing model from the issue text.