Adapt `flt.utils.trimmer` to current API

Adapt `flt.utils.trimmer` to current API

This patch is a 99% rewrite of the `flt.utils.trimmer` component class.

An `flt.utils.trimmer` component still supports the `begin` and `end`
parameters, each one being optional, to configure its bounds. You can
still specify a time without a date for its message iterators to find
the date automatically and apply the time over it. The supported
date/time formats are:

    YYYY-MM-DD hh:mm:ss.nnnnnnnnn
    YYYY-MM-DD hh:mm:ss
    YYYY-MM-DD hh:mm
    hh:mm:ss.nnnnnnnnn
    hh:mm:ss
    ss.nnnnnnnnn
    ss
    -ss.nnnnnnnnn
    -ss

The `gmt` boolean parameter controls whether or not the time strings
express UTC or local times.

An `flt.utils.trimmer` message iterator keeps a state for each stream it
encounters. This is needed to generate some messages that could be
missing at the beginning and at the end of the trimming range for each
stream.

An `flt.utils.trimmer` message iterator initially makes its upstream
message iterator seek the trimming range's beginning time, so that the
seeking operation performs the initial message skipping. This means that
the upstream message iterator must support seeking for a trimmer message
iterator to work with it. The iterator fails gracefully when the
upstream message iterator cannot seek.

Another constraint is that an `flt.utils.trimmer` message iterator only
works with messages having a default clock snapshot. This is obvious
considering the iterator's purpose.

Initial and final stream activity messages are of particular interest.
The implemented algorithm is as such:

Stream beginning message:
    Known time:
        Inside trimming range:
            Accept message as is.

        Outside trimming range:
            Standard end of trimming range condition.

    Unknown time:
        Accept as is.

    -inf time:
        Generate new stream beginning message having the trimming
        range's beginning time as its time.

Missing stream beginning message:
    Generate new stream beginning message having the trimming
    range's beginning time as its time.

Stream end message:
    Known time:
        Inside trimming range:
            Accept message as is.

        Outside trimming range:
            Standard end of trimming range condition.

    Unknown time:
        Accept as is.

    +inf time:
        Generate new stream end message having the trimming range's end
        time as its time, and emit it only when reaching the end of the
        trimming range.

Missing stream end message:
    Generate new stream end message having the trimming range's end time
    as its time.

Discarded events and packets messages can also be modified (that is,
discarded and then the iterator creates a new, similar message) to
narrow their time range if it's outside the trimming range. When this
occurs, the message's count property is not copied: we can't know how
many events/packets were discarded in the new time range.

Each `flt.utils.trimmer`¸message iterator has an output message queue.
When the iterator's "next" method is called, it gets the next upstream
message iterator's messages until the output message queue contains
something, handling each received message to drive the per-stream state
machines which can or cannot push messages to the queue (state_trim()
function). Then it pops messages from the queue to fill the outgoing
message array.

When the upstream iterator is ended, the trimmer iterator walks the
current stream states and pushes the appropriate messages to the queue
to correctly end each one, and then removes all the stream states. The
state becomes `TRIMMER_ITERATOR_STATE_ENDING` until the queue is empty,
in which case it becomes `TRIMMER_ITERATOR_STATE_ENDED` of which the
only purpose is to return the `BT_SELF_MESSAGE_ITERATOR_STATUS_END`
status.

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