lib: make packet beginning/end default CS optional

lib: make packet beginning/end default CS optional

This patch makes it possible to create packet beginning and end messages
using bt_message_packet_beginning_create() and
bt_message_packet_end_create(), that is, without default clock
snapshots, even if the corresponding stream class has a default clock
snapshot. This was considered like a precondition break before this
patch.

Rationale
=========
The main use case for this is to support sources which do not have a
concept of beginning and end times for their packets, but which have
times for their events. Currently, such sources need to make up default
clock snapshot values for those packet messages.

This can be the case of `src.ctf.fs` which, when a given stream class's
packet context does not contain the `timestamp_begin` and
`timestamp_end` members, uses the current default clock's value during
the stream decoding process, except for the beginning time of the first
packet which is set to 0. This is problematic because it means the
stream is active from clock value 0 to the first event, which is
probably not true. A solution would be to use the first event's time in
this scenario, but:

* Several packets can be empty at the beginning, making the task
  difficult because we need to queue pseudo-messages until we have the
  first event's time and then create the real messages with this value.

* All packets can be empty, so no specific time value is available for
  the whole stream.

Although they are weird scenarios, they can still happen. Using 0 for
the first packet's beginning time is just wrong in those cases.

Other sources which do not need the concept of a packet can use this
new feature too: `src.text.dmesg` is one of them.

Library changes
===============
As with other features of stream-related objects, the default clock
snapshot property is not optional _per_ packet beginning/end message:
for the streams of a given stream class, either all packet beginning
and/or end messages have a default clock snapshot, or they don't.

This is controlled by a new stream class flag of which the API is:

    void bt_stream_class_set_packets_have_default_beginning_clock_snapshot(
        bt_stream_class *stream_class, bt_bool value);

    void bt_stream_class_set_packets_have_default_end_clock_snapshot(
        bt_stream_class *stream_class, bt_bool value);

    bt_bool bt_stream_class_packets_have_default_beginning_clock_snapshot(
        const bt_stream_class *stream_class);

    bt_bool bt_stream_class_packets_have_default_end_clock_snapshot(
        const bt_stream_class *stream_class);

By default, a stream class has no default clock class, so its packets
are also known to have no beginning/end default clock snapshots. When
you call
bt_stream_class_set_packets_have_default_beginning_clock_snapshot() or
bt_stream_class_set_packets_have_default_end_clock_snapshot(), you must
have called bt_stream_class_set_default_clock_class() first. This means
you can check if a packet beginning message, for example, has a default
clock snapshot with
bt_stream_class_set_packets_have_default_beginning_clock_snapshot()
without also checking
bt_stream_class_borrow_default_clock_class_const().

It is required that you have called
bt_stream_class_set_packets_have_default_beginning_clock_snapshot() in
order to use
bt_message_packet_beginning_create_with_default_clock_snapshot() for the
corresponding stream class. Same thing for
bt_stream_class_set_packets_have_default_end_clock_snapshot() and
bt_message_packet_end_create_with_default_clock_snapshot().

This is all validated in developer mode.

Plugin changes
==============
Component classes are changed as such:

`src.ctf.fs`:
`src.ctf.lttng-live`:
    In order to separate concerns into different patches, the procedure
    is not changed in this component class: all packet beginning/end
    messages have a default clock snapshot when the corresponding stream
    class has a default clock class, even if the stream class's packet
    context does not contain the `timestamp_begin` and `timestamp_end`
    members.

    Another patch will fix this issue.

`src.text.dmesg`:
    Like `src.ctf.fs`, the procedure is not changed: all packet
    beginning/end messages have a default clock snapshot when the
    corresponding stream class has a default clock class.

    The simplification change will be done in another patch.

`flt.utils.trimmer`:
    Stream classes without a default clock class are already not
    supported. With this patch, packet beginning/end messages without a
    default clock snapshot are not supported.

    The support will be added by another patch.

`flt.utils.muxer`:
    When a packet beginning/end message does not have a default clock
    snapshot, the iterator's last time is used to sort the messages.
    This is similar to other messages without a default clock snapshot.

`flt.lttng-utils.debug-info`:
    Stream class properties and packet beginning/end messages are copied
    considering the new feature.

`sink.ctf.fs`:
    Packet beginning/end without a default clock snapshot, but with a
    stream class which has a default clock class, are not supported.

    Support will be added by another patch.

All the tests still pass because, even though some filter/sink
components do not fully support the new feature, the existing sources do
not use it yet.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I7183bfe8f954235c7f54195b101f781b176ab733
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1361
Tested-by: jenkins