Add bt_graph_add_component(), make bt_component_create() internal

Add bt_graph_add_component(), make bt_component_create() internal

With this patch, you can only instantiate a component class through an
existing graph. This can guarantee to the user (component class
developer) that, when the component class's initialization method is
called, the component always belongs to a graph. This simplifies things,
now and in the future. For example, it is possible to cancel the graph
during the execution of bt_graph_add_component() so that the user method
knows if it should retry now or return an error when the graph is
canceled.

bt_graph_add_component() returns BT_GRAPH_STATUS_CANCELED if the graph
is canceled. If the user's initialization method fails, its return
component status is converted to the appropriate graph status.

Another advantage of adding a component to a graph is that, if you add a
"port added" graph listener, it is guaranteed that the listener is
called even for the initial ports of a component. This was not possible
before.

This patch also makes a component's name mandatory, and
bt_graph_add_component() ensures that there are components sharing the
same name part of a given graph. This is a constraint similar to the
fact that all the ports of a component must have a unique name. It
should help to the implementation of a function to retrieve a component
by name from a graph in the future.

We do not check that a graph has or not "loose", disconnected components
in bt_graph_consume(). This is not a change because any component can
remove all its ports once connected once and become loose. A graph with
floating/loose components is said to be disconnected in classical graph
theory. This is not a problem for the moment, as the connected
components can still interact. The disconnected components should
probably be marked and then destroyed in bt_graph_consume() and/or in a
dedicated garbage collecting function if needed
(bt_graph_remove_disconnected_components() for example).

This patch also makes successfully user-initialized components marked as
such so that the user's finalization method is not called if its
initialization method failed. In other words, the initialization method
is responsible for any cleanup if it's about to fail.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>