lib: add sink component class's "graph is configured" method

lib: add sink component class's "graph is configured" method

All filter component classes implement the same logic currently to
support their instance being connected input first or output first.

Before this patch, if a filter component was connected to a sink
component, the sink component's "input port connected" method was called
and this is where the sink component had to create an input port message
iterator. This made the filter message iterator initialize, but it was
possible that the filter's input ports were not connected yet. To
support this connection order, the filter message iterator had to add
itself to a list of iterators within the component's private data, and
upstream iterators had to be initialized when the filter component's
"input port connected" method was called. Also, when the filter message
iterator was finalized, it had to remove itself from the component's
list. This strategy worked, but it was cumbersome and did lead to
duplicated code amongst different filters.

This patch does the following:

* It makes the graph have two phases: configuration and
  post-configuration. The configuration phase is when you create and
  connect components. The post-configuration is as soon as you call
  bt_graph_run(), bt_graph_consume(), or
  bt_port_output_message_iterator_create().

* It makes it incorrect (validated in developer mode) to create an input
  port message iterator during the graph's configuration phase. In other
  words, an "input port connected" method cannot call
  bt_self_component_port_input_message_iterator_create() anymore.

* It adds an optional sink component class's "graph is configured"
  method. This method is considered to be called when the graph is
  configured (post-configuration phase): it is called at the beginning
  of bt_graph_run() or bt_graph_consume() when it was not previously
  called.

  This is where a sink can call
  bt_self_component_port_input_message_iterator_create() now. This leads
  to a chain of message iterator initialization which all occur during
  the post-configuration phase. This guarantees to the initialization
  methods that ports are connected, and that disconnected ports will
  never be connected.

This is not a big change for sink component classes, if any: for the
`sink.text.pretty`, `sink.utils.counter`, and `sink.utils.dummy`
component classes, the "input port connected" method is simply replaced
with the "graph is configured" method.

This is however a big change for filter component classes. For example,
the `flt.utils.muxer` component class is much simpler as of this patch:
it simply creates all its upstream message iterators in its message
iterator initialization method, and hundreds of lines of codes are
removed.

Checking that the graph is configured at the beginning of
bt_graph_consume() could potentially have a performance impact, but I
did not measure this. If it's the case, then we would need a dedicated
graph function, for example bt_graph_confirm_configuration(), to call
the "graph is configured" methods once before calling bt_graph_consume()
in a loop.

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