lib: do not allow port to be removed when message iterators are active

lib: do not allow port to be removed when message iterators are active

This patch makes it illegal to remove a port when at least one message
iterator using it is not finalized (or in the process of being
finalized).

This introduces the following advantages:

* From a downstream point of view, your upstream message iterator cannot
  randomly get canceled, because a connection cannot end while any
  message iterator is active.

  Therefore the `BT_MESSAGE_ITERATOR_STATUS_CANCELED` status is removed.
  This status was ambiguous and there was no clear indication of what to
  do when you get it. Current plugins were handling it like
  `BT_MESSAGE_ITERATOR_STATUS_END`.

* There's a precondition that you when you call
  bt_self_component_port_input_message_iterator_next(), the iterator
  must be active. In practice this is always the case because the only
  way for it to be finalized if when you actively put its last
  reference, and you should know it.

  Therefore bt_self_component_port_input_message_iterator_next() does
  not need to check the "finalized" status every time you call it in
  case it needs to return the removed
  `BT_MESSAGE_ITERATOR_STATUS_CANCELED` status.

To distinguish between "finalized" and "in the process of being
finalized", the (internal)
`BT_SELF_COMPONENT_PORT_INPUT_MESSAGE_ITERATOR_STATE_FINALIZING` is
introduced: when a message iterator is finalized, its state is set to
`BT_SELF_COMPONENT_PORT_INPUT_MESSAGE_ITERATOR_STATE_FINALIZING`, then
its finalization method is called, then its state is set to
`BT_SELF_COMPONENT_PORT_INPUT_MESSAGE_ITERATOR_STATE_FINALIZED`. You can
remove a component's port when all its message iterators have one of
those states.

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