libvlc: add tracer callback support

This merge request adds the libvlc API and core handling for tracer support.

To achieve that goal, the initial requirements have been respected on the tracing path:

• no memory allocations,
• no locks,
• no formatting and
• no indirect function calls.: There's an indirection level added to support the switching mechanism, which works the same way as the logger switcher.

It needed to provide a mechanism for non-racy tracer switching, which has been solved by imitating the log system and the use of the RCU algorithm to avoid waiting in trace() and still wait for traces to have switched to the correct variant before destroying the previous tracer.

It's still a draft since multiple questions have not been addressed. I would like to use some feedback on those before continuing, and any other point I might have missed on the way here.

1/ fine-grain tracing: how to enable only a subset of traces in a performant way, and how to describe this subset in the libvlc interface

I think that we could still integrate the API with a reserved field (a null-terminated array of string?) to describe the enabled traces but we need an efficient way to enable on the core side afterwards. Maybe we can:

• provide the array to libvlc_priv
• extend vlc_object_get_tracer to select the wanted traces or store an intermediate object to replace it
• have a lock-free mechanism (triplet of integer in atomic for instance) to signal a fine-grain trace selection change

It would mean that:

• no tracer is still a no-cost path
• fine-grain tracing can be changed live to match what needs to be observed
• the intermediate object could provide a low-cost check and cache whether the trace is enabled on not

2/ libvlc entry API

The current API exposed for libvlc completely mimics the entries present in vlc core, which is of course wrong since it's not exposed.

There would be at least two alternatives here:

• provide a dedicated object to loop over the different entries, probably doable without allocation since we control the callback, but it's an additional hop and additional object.
• provide the definition of an entry pointer on the libvlc side, which means that the object must match completely.

3/ libvlc tracer modules

In this MR, there are no way to select an existing tracer module, mostly because there is still no way to discover those modules for the libvlc application developer (like filters, sout, etc). With a discovery plugin / plugin discovery API like discussed in the workshop, it would be possible to expose endpoints to create objects matching those tracers, but a libvlc entrypoint will still be needed to assign a libvlc_tracer object created this way. It means that the API will both have a libvlc_instance_set_tracer(object) and libvlc_instance_set_tracer_callbacks(callbacks) whereas the callback version could have been a dedicated creation function giving a libvlc_tracer from the beginning.

If we don't have a discovery plugin/ plugin discovery API, the question doesn't arise, but I don't have any solution for the modules, except hardcoding in the API like the logger.