lib: add default clock snapshot property to packet beginning/end message

lib: add default clock snapshot property to packet beginning/end message

Packet beginning/end clock snapshot properties were removed from the
`bt_packet` object in a previous commit because they were considered
redundant with the time ranges given by the recently added discarded
events/packets messages.

Now it seems that those properties are needed in order for a message
iterator such as `flt.utils.trimmer` to know whether or not a given
packet beginning/end message is within a given time range. This removes
uncertainty for a class of filters and sinks.

The CTF format has a concept of packet with a specific end time in its
context, but not all source formats have this chance. For this reason,
instead of putting the beginning and end clock snapshot properties in
the `bt_packet` object itself, which would require any source to know
its packet's end time in advance, the packet beginning/end message
itself contains the property. For example, in this patch,
`src.text.dmesg` is modified to set the first event's clock snapshot as
the single packet beginning message's clock snapshot, and the last
event's clock snapshot as the single packet end message's clock
snapshot. Similar sources should take this approach, as those fields are
mandatory if the message's packet's stream's class has a registered
default clock class.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>