AAF Reader: TimeEffect on clip causing nested scope / potential structure issue?

Investigating how motion effect information is coming through in the OTIO structure, I have just come across a few things that raise some questions on our end - possibly something that may be intentional; maybe something that hasn't been spotted yet.

As a baseline test, exporting an AAF from Premiere with a single clip on a single track with no motion effect applied gives us the OTIO structure we would expect:

```
"OTIO_SCHEMA": "Timeline.1",
...
"tracks": {
"OTIO_SCHEMA": "Stack.1",
"children": [
{
"OTIO_SCHEMA": "Track.1",
"children": [
{
"OTIO_SCHEMA": "Clip.1",
"name": "CLIP_1_NoMotionEffect",
...
```

When another clip is added on to the second track ("V2") and has a motion effect applied to it (Clip Speed at 50%), the resulting OTIO structure looks like this:

```
"OTIO_SCHEMA": "Timeline.1",
...
"tracks": {
"OTIO_SCHEMA": "Stack.1",
"children": [
{
"OTIO_SCHEMA": "Track.1",
"children": [
{
"OTIO_SCHEMA": "Stack.1",
"children": [
{
"OTIO_SCHEMA": "Clip.1",
"name": "CLIP_1_NoMotionEffect",
...
},
{
"OTIO_SCHEMA": "Track.1",
"children": [
{
"OTIO_SCHEMA": "Gap.1",
"name": "Filler",
...
},
{
"OTIO_SCHEMA": "Clip.1",
"name": "CLIP_2_WithMotionEffect_50%",
...
```

The first real question here is: should this be respecting (what seems to be) the intended structure of `Stack -> Track -> Clip`? There are a few cases now that I've come across where this hierarchy isn't respected when importing AAFs and you end up with a `Stack -> Clip` relationship. The second, ultimately more important, questions is: is it intentional that this kind of structure can and should exist, or should it always be following the `Stack -> Track -> Clip` hierarchy?

You can see here that there is no nesting happening that should indicate for this first clip to be included inside a nester scope:


Would this be the result of how the information is packaged when exported to AAF, or of how PyAAF/OTIO are interpreting the information?

When the same sequence is exported to XML, it is working exactly like we would expect - following the normal structure with no nested scopes, so we would hope to be able to get consistent results between the two.

Zip attached with a copy of the AAF and XML for you to check out:

[NewSpeedChange_MstrSeq_Examples_190408.zip](https://github.com/PixarAnimationStudios/OpenTimelineIO/files/3052691/NewSpeedChange_MstrSeq_Examples_190408.zip)

As always, just let me know if there's any further info I can provide. Now that we are able to start testing AAFs with nested sequences, I have come across a few other issues that potentially fall in to a similar category, but will create a separate issue for them.