Now that the notion of layer has been moved down to #GESTimelineElement
(through the new #ges_timeline_element_get_layer_priority method), this
method make much more sense directly in the base class.
ges_container_add removes the child being added if the call to
ges_timeline_element_set_parent fails. In this case, subclasses should
be given the chance to revert the effects of the add_child vmethod which
has just been called.
These are showing up in performance profile of 1000+ clips looped addition.
All this is done at commit time as well, so let that do only one update and
sorting.
Discoverer maintain a referernce on the discoverer object while
the async timeout callback is alive to prevent a potential crash
if the object is freed while the callback is pending.
But if g_main_context is released before calling the timeout callback,
the discoverer pointer which was weak referenced from GESUriClipAssetClass
will not be disposed because the discoverer object is not finalized.
This suppresses the annoying 'g-ir-scanner: link: cc ..' output
that we get even if everything works just fine.
We still get g-ir-scanner warnings and compiler warnings if
we pass this option.
And handle the fact that adding to a layer can fail.
Also plug some leaks in the dispose method (and use the dispose
vmethod instead of finalize as appropriate).
Basically if we do not emit a "duration" change of the clip being
splitted first when executing the 'reverse' operations would lead
to fully overallaping clips.
This is implemented on top of a Tree that represents the whole timeline.
SourceClips can not fully overlap anymore and the tests have been
updated to take that into account. Some new tests were added to verify
that behaviour in greater details
Each timeline element is in a layer (potentially spanning
over several), it is very often useful to retrieve an element
layer priority (from an app perspective more than the element
priority itself as that is a bit of an implementation detail
in the end).
Port tests to it
