Fix: lib: strengthen clock expectation check for no Unix epoch / no UUID case

When an iterator sees a clock class with an origin that is not the Unix
and has no UUID, it sets its clock expectation to
CLOCK_EXPECTATION_ORIGIN_OTHER_NO_UUID.  In this mode, when validating
subsequent clock classes, it validates that the clock class' origin is
not the Unix epoch and that it has no UUID.  This is too loose: an
iterator could send messages with two distinct clocks with unknown
origins and no UUID, and it would pass validation.  However, these two
clock classes are not correletable.

Fix that by making the iterator remember which specific clock class
instance it saw first.  Each subsequent message must have exactly that
clock class instance.

To be sure that a clock class an iterator has saved doesn't get freed,
and then a new one reallocated at the same address, the iterator takes a
strong reference to the clock class.  This ensures that the saved clock
class at least outlives the iterator.

TODO: I would like to write a test for this

Change-Id: I339936b730fe2f4e64dbc58d56557ffcd23cce16
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11448
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>