AAF Reader: Incorrect Clip Source Times

So, bear with me on this one... it's a little complicated; a little confusing; and I'm still trying to piece together as many of the exact details as I can.

I'm just starting to notice a very serious issue with `available_range`'s in a clip's `media_reference` (and `source_range`) coming through from Media Composer AAFs.

There appears to be inconsistency in when the the correct `start_time` is used from the underlying AAF data. I am yet to see a specific reason/pattern as to when this is happening, so best I can do at this point is just give as much info as I can for the situation.

----------------------

**ExampleClip_col_mat12_v025_p005**

This clip has source timecode values of In: `00:00:41:21` and Out: `00:01:08:16`, but the `available_range`/`source_range` object generated by OTIO comes through as:

```
"available_range": {
"OTIO_SCHEMA": "TimeRange.1",
"duration": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 643
},
"start_time": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 4
}
},
...
"source_range": {
"OTIO_SCHEMA": "TimeRange.1",
"duration": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 643
},
"start_time": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 4
}
}
```

Using this info, we get source timecode values of In: `00:00:00:04` and Out: `00:00:26:23`. The correct timecode values above were generated by opening the AAF in Media Composer and exporting EDLs, and the incorrect timecode values (the `available_rage` object) were generated by reading the same AAF using OTIO.

Consulting this specific clip's info in the Media Composer bin we see:


From this, it appears that the `Start (TC)` and `Aux TC1` fields are being ignored, and simply the frames being used are determining the `available_range` - frames 4 (`00:00:00:04`) through 647 (`00:00:26:23`) of the total 651 available.

----------------------

The inconsistency appears then looking at another version of the same clip that exists below this one on the multi-track timeline....

**ExampleClip_col_v024**

This clip also has source timecode values of In: `00:00:41:21` and Out: `00:01:08:16`, but the `available_range`/`source_range` object generated by OTIO comes through correctly as:

```
"available_range": {
"OTIO_SCHEMA": "TimeRange.1",
"duration": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 652
},
"start_time": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 1000
}
},
...
"source_range": {
"OTIO_SCHEMA": "TimeRange.1",
"duration": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 643
},
"start_time": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 1005
}
}
```

...and this specific clip's info in the Media Composer bin:


----------------------

From this I might think that it perhaps has something to do with the `Mark In` field that has been set on the clip, but there is also another clip here (again, a different version of the same clip stacked underneath) that has these fields set:


...and again the `available_range` and `source_range` objects are not correct, with a value of:

```
"source_range": {
"OTIO_SCHEMA": "TimeRange.1",
"duration": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 643
},
"start_time": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 23.97602397602398,
"value": 4
}
}
```

...for both.

I have put together some examples files as best I can given the sensitive content of the AAF that these errors have come from. There is a screen shot of the relevant Media Composer clip info and the OTIO Clip schema for each clip, along with a screenshot of the Media Composer bin and the EDL info that MC exports for these clips.

[AAF_SourceReadingError_ExampleFiles_190603.zip](https://github.com/PixarAnimationStudios/OpenTimelineIO/files/3246395/AAF_SourceReadingError_ExampleFiles_190603.zip)

Unsure as to whether this may be more something to address with PyAAF as opposed to here, but figured it worth raising the issue here so everyone's aware and see what the best approach to figuring out a solution might be.

Start with the attached AAF_SourceReadingError_ExampleFiles_190603.zip and the AAF reader's available_range/source_range handling. Compare the example clips with the Media Composer bin information and exported EDLs; done means the reader consistently produces the expected source timecodes.

Written by the indexing model from the issue text.