Refactoring the multiple tracing mechanisms

Summary

The master branch currently implements 2 methods for tracing events:

• many macros allow to record fxt events that depict various events in starpu (task submission, data transfers, scheduling points, memory management, synchronization, ...)
• a few function calls allow to invoke external tracing tools (eg. APEX, EZTrace) callbacks. This is mainly for task submission/execution and data transfers.

This merge request refactors the tracing mechanism:

• calls to fxt macros (_STARPU_TRACE_*) are replaced with calls to functions (starpu_trace_) implemented in src/profiling/starpu_tracing.c
• the tracing functions may then call a tracing tool (eg. fxt, APEX, EZTrace, ...) to record an event

Pros

With this MR, tracing tools could record a wide variety of events describing StarPU internals (the ones that are currently recorded with fxt).

Cons

The drawback is that starpu will perform a function call for each tracing point, event if no tracing tool is running. Experiments show that this does not impact performance. When running tests/microbench/tasks_overhead.c on the master and starpu_tracing branch, I get the following performance

Tracing disabled

• master branch

count  20.000000
mean    9.069349
std     0.082912
min     8.898763
25%     9.004024
50%     9.072847
75%     9.137673
max     9.179342

• starpu_tracing branch

count  20.000000
mean    9.004310
std     0.120586
min     8.798157
25%     8.920452
50%     9.004300
75%     9.105185
max     9.211646

Tracing enabled (using FxT)

• master branch

count  20.000000
mean   22.841427
std     0.562184
min    21.619330
25%    22.705669
50%    23.063895
75%    23.195788
max    23.406241

• starpu_tracing branch

count  20.000000
mean   22.698880
std     0.773609
min    20.821998
25%    21.961076
50%    22.944935
75%    23.305813
max    23.562601