Fix: flt.utils.muxer: reject two different clock classes with unknown origin and...

Fix: flt.utils.muxer: reject two different clock classes with unknown origin and no UUID

When getting a message with a clock class whose origin is unknown and
that has no UUID, the expectation of a `flt.utils.muxer` component
should be that all subsequent messages with an associated clock class
will have the exact same clock class instance.  Currently, it accepts
any other clock class instance that has an unknown origin and no UUID.

This is a change that is equivalent to what was done in commit
29e191fceb61 ("Fix: lib: strengthen clock expectation check for no Unix
epoch / no UUID case") in the library iterator code.

When first seeing a clock class with unknown origin and no UUID, make
the muxer message iterator save the clock class instance, holding a
strong reference, and ensure that all clock classes seen after are the
same instance.

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