Display teardown: Fix race condition in flushing logic

fadfe6e3 added flushing to Display teardown to fix long delays when using
non-live sources.  It also introduced a test that graceful shutdown would
work.  Unfortunately the test revealed that the fix was racy.  This was
causing intermittant failures on Travis and could be readily reproduced
on a VM.

The race was between the EOS event and the pipeline getting started up
again after FLUSH_STOP.  After receiving FLUSH_STOP the videotestsrc
element would start sending events and buffers again.  This would fill up
the queues and then the EOS event would get stuck behind the buffers in
the queues, just like before the fix in fadfe6e3.  This commit fixes this
by sending EOS before FLUSH_STOP.  This has the effect that once the
source receives FLUSH_STOP it will immediately send out the EOS without
sending any SEGMENT events or buffers.

Originally I'd been reticent to do it this way as my understanding of
FLUSH events was that they would cause any events between FLUSH_START
and FLUSH_STOP to be disregarded.  This is true, but GstBaseSrc is
intelligent enough to store them up for later transmission after
FLUSH_STOP.  It terms this `pending_eos`.