ir: refactor FT validation and resolving

ir: refactor FT validation and resolving

This patch refactors the CTF IR field type validation and the
resolving of variant/sequence field types.

First, validation is completely decoupled from the objects
containing the field types. In other words, validation does not
know the exact event class, stream class, or trace in which the
field types to validate are or are supposed to be. Only field types
are given to the validation function, which is isolated in its
own file.

To make the life of the resolving engine easier, all scopes are
deep-copied before reaching it. This is done during the validation
process. This ensures that no two field types in the whole
hierarchy refer to the same object in memory. This greatly simplifies
the resolving process, while adding insignificant overhead since
this is only done once. The copies do not replace the original types
until we are sure that the object to be validated (event class, stream
class, or trace) is valid and will be frozen. When it is the case, a
valid flag is set, which avoids validating the object again in the
future when calling the same function. If the object is not valid,
then the copies of its field types are discarded, and the function
fails.

Validation is done at three important places:

  * bt_ctf_event_create(): when creating an event, because we don't
    want the user to obtain an event linked to an invalid event
    class. It is possible to create an event from an even class
    which has a parent stream class which has no parent trace. In
    this case, no variant/sequence field type in all the field types
    of the stream class and event class can be resolved to the
    trace packet header field type.
  * bt_ctf_stream_class_add_event_class(): when adding an event class
    to a stream class AND when the stream class has a parent trace,
    because in this case the whole hierarchy exists and everything
    is frozen, so it makes sense that everything in there should be
    valid. If the stream class has no parent trace yet, then the
    validation will be done when adding it to a trace using the
    following function. This is because the added event class could
    contain a variant/sequence field type which resolves to a field
    type of the trace packet header field type, contained in the trace
    object.
  * bt_ctf_trace_add_stream_class(): when adding a stream class to
    a trace, because in this case both the trace and the stream
    class will be frozen, and hence they should be valid because they
    cannot be changed anymore.

The test_ctf_writer test is updated here to follow those changes. Since
the field types can be copied when calling one of the above functions,
we cannot create a field out of an original field type and then compare
its address to a field obtained from the created event or stream: we must
put the original field types and obtain the new ones from the event class
or stream class. The contents of field types are compared using
bt_ctf_field_type_compare() instead.

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