FCP7 XML: Clip duration calculated incorrectly, causing out-of-sync timeline construction

The attached FCP7 XML, exported from Premiere, includes a placeholder clip which declares a duration of 0 and a rate for that duration of 0. Apart from causing NaN values in the OTIO model, the current XML adapter does not correctly find the actual clip duration as used on the timeline, causing every subsequent clip on that track to be out of sync with the actual film, and with every other track in the model.

The sequence does however, round-trip from Premiere - XML - Premiere without losing data, proving that the timeline duration information is not lost.

I propose that the duration of a clip (in the context of the timeline) needs to be calculated from the 'start' and 'end' fields rather than relying on source duration with applied timewarp effects.

1. Mac OS12.3
2. Python 3.9
3. example OTIO commit: ebd15cd618b98ce432c4d5efdd95368422cdb256
4. Ingest the attached XML thru the OTIO FCP7 XML adapter
5. if your viewer crashes- you may need to handle NaN values in the JSON - I did a find/replace with 'null'

## Expected Behavior
Ideally, the placeholder clip would have its duration in the timeline correctly interpreted and an OTIO object inserted for that duration. The OTIO model would have the ".MOV" clip starting around 01:00:15:00

## Actual Behavior
The clip duration information is lost and any app trying to read the OTIO data will see every clip after that time as being out of sync by the bogus clip's actual duration. A serious data corruption. The OTIO model has the ".MOV" clip starting at beginning of timeline.

## Screenshots
Test sequence in Premiere, prior to exporting as XML.
Same sequence as interpreted by OTIO, ignoring the error-causing clip.

## Additional Context
I think it is vitally important that, where available, the actual timeline insertion length is used as the clip duration. Using the source duration and attempting to interpret varispeed, interpolation and timewarp effects is inherently fragile. The damage caused by mis-interpreting a timewarp or rounding a frame count in the wrong direction is severe. Any possible side effect of relying on the timeline insertion length is both unlikely and isolated to the clip in question.

Attached is and example XML, exported form Premiere, with and without transitions.
NOTE: the sequence starts at 00:59:50:00 (sorry)
[GTTestXMLs.zip](https://github.com/AcademySoftwareFoundation/OpenTimelineIO/files/8819709/GTTestXMLs.zip)

Start with the FCP7 XML adapter and ingest the attached GTTestXMLs.zip XML files using the reproduction steps. Compare the resulting OTIO model with the Premiere timeline, especially the placeholder clip and the .MOV clip expected near 01:00:15:00. Done means the placeholder has the correct timeline duration, no NaN values are produced, and later clips remain synchronized.

Written by the indexing model from the issue text.