Fix: flt.utils.trimmer: no error when upstream can not seek

Fix: flt.utils.trimmer: no error when upstream can not seek

Issue
=====
According to commit 7de0e49, every upstream message iterators of a
`flt.utils.trimmer` must support seeking. If it's not the case, the
graph should fail gracefully.

I encountered a situation where this invariant is not held. I can
reproduce this issue by commenting out the `_SEEK_BEGINNING_METHOD()`
and `_CAN_SEEK_BEGINNING_METHOD()` of the `flt.utils.muxer` and ran the
following graph:
  babeltrace run \
	  --component=src:src.ctf.fs \
		  --params='paths=["/home/frdeso/lttng-traces/auto-20181210-133612"]' \
	  --component=mux:filter.utils.muxer  \
	  --component=trim:filter.utils.trimmer \
		  --params='begin="13:36:12.871289834",end="13:36:12.871303475"' \
	  --component=sink:sink.text.pretty \
	  \
	  --connect=src.*:mux.* \
	  --connect=mux.*:trim.* \
	  --connect=trim.*:sink.*
Note: The `begin` and `end` parameters are event timestamps from the trace.

When the trimmer component sees that seeking is not supported, it simply
skip the seeking and continue. This triggers a `BT_ASSERT()` later on.

See commit message 7474e7d3f0d005280c6614be5c818735e65d8b3b for more details on
seeking.
See commit message 7de0e49a7c4bb3c04075703e6767d15b7beb277f for more details on
trimmer.

Solution
========
Error out if seeking is disabled on upstream message iterators.

Drawbacks
=========
None.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I35cdec3b8eac54f2f596d0f50661608b624d3e2e
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1325
Tested-by: jenkins
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>