cpp-common/bt2: add `bt2::Const*Component` and `bt2::Const*Port`

cpp-common/bt2: add `bt2::Const*Component` and `bt2::Const*Port`

This patch adds the `bt2::ConstComponent`, `bt2::ConstSourceComponent`,
`bt2::ConstFilterComponent`, and `bt2::ConstSinkComponent` wrapper
classes to wrap resp. `const bt_component`, `const bt_component_source`,
`const bt_component_filter`, and `const bt_component_sink`.

I didn't find a clever way to make `bt2::ConstSourceComponent`, for
example, inherit `bt2::ConstComponent`, because they manage different
library types (`const bt_component` vs. `const bt_component_source`). I
think this is a first in `src/cpp-common/bt2` for this situation: for
example, all value objects have the `bt_value` type, all field classes
have the `bt_field_class` type, and so on, making it possible to also
express the intended relations in C++.

I though about using a library upcasting function (for example,
bt_component_source_as_component_const()) to call the parent
constructor, but then there would be no "safe" way to return to
`const bt_component_source` because there aren't downcasting functions
(`reinterpret_cast<const bt_component_source *>()` would probably work,
but isn't super legit).

Therefore there's no relation between specific component wrapper classes
and `bt2::ConstComponent`. That being said, `bt2::ConstComponent` is
courteous and offers all the copy constructors and assignment operators
to copy and assign from specific component wrappers. For example:

    void f(const bt2::ConstComponent myComp)
    {
        // ...
    }

    void g(const bt_component_source * const libCompPtr)
    {
        const bt2::ConstComponent comp {libCompPtr};
        const bt2::ConstSourceComponent srcComp {libCompPtr};

        f(srcComp);
    }

However, the shared versions aren't directly compatible because the
reference count functions aren't the same (an obvious requirement to
construct a shared object from another one). To make things easier, each
specific component wrapper class has the sharedComponent() method which
returns a `bt2::ConstComponent::Shared` instance:

    void f(bt2::ConstComponent::Shared myComp)
    {
        // ...
    }

    void g(bt2::ConstSourceComponent::Shared srcComp)
    {
        f(srcComp->sharedComponent());
    }

Each specific component wrapper class kindly offers the name() and
loggingLevel() methods to avoid going to a `bt2::ConstComponent` by
hand.

Each specific component wrapper class has its inputPorts() and/or
outputPorts() method(s). Those return an instance of
`bt2::ConstComponentPorts` with the appropriate template arguments to
make things just work. `bt2::ConstComponentPorts` has the length()
method and various `[]` operators to access ports:

    mySrc.outputPorts()[3]

    myFlt.inputPorts()["file2"]

The returned object is one of `bt2::ConstInputPort` or
`bt2::ConstOutputPort` wrapping resp. `const bt_port_input` and
`const bt_port_output`.

Component and port wrapper classes are part of the same header,
`component-port.hpp`, for the same reason all high-level trace IR
wrapper classes are in the single `trace-ir.hpp`: a port object may
return a component (component() method) and a component object may
return a port (inputPorts()/outputPorts() methods), making it difficult,
if not impossible, to use two different headers because we don't know
the inclusion order of the user.

Because the libbabeltrace2 API always deals with specific (input or
output) port objects, there's no `const bt_port` wrapper class: you
always use `bt2::ConstInputPort` or `bt2::ConstOutputPort`. In other
words, no API function returns a general `const bt_port` pointer.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I1324a59c8291cb83a432eeb7477c6b3e353924f5
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11184
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>