Refactoring and fix: bytecode ABI

Introduce an "event filter" callback to be called by the instrumentation
probe, and move the bytecode list into private data structures.

This will allow much more freedom in choosing how bytecodes are combined
both in terms of logic (OR vs AND) and implementation (jits).

Currently, we keep callbacks internally as well for each bytecode
evaluation, but nothing prevents to change how this works in the future
to improve performance now that this is all private.

For filters, we add the following fields to struct lttng_ust_event_common:

       int eval_filter;                                /* Need to evaluate filters */
       int (*run_filter)(struct lttng_ust_event_common *event,
               const char *stack_data,
               void *filter_ctx);

"eval_filter" is a state indicating whether the filter should be
evaluated at all. It combines internal knowledge of whether the filter
bytecode list is empty, and whether there are enablers without filter
bytecode attached to the event.

For captures, a new struct lttng_ust_notification_ctx is introduced,
which is to be used as additional "context" to the notification_send()
callback. This allows passing the "eval_capture" state from the probe
to the notification callback, and fixes a bug where a sequence of:

- create notification enabler,
- enable notification enabler,
- add capture to enabler,

where a tracepoint runs concurrently with add capture happens to do a
first capture list_empty check which skips the stack preparation,
whereas the second capture list_empty check within the notification
callback finds a capture entry, and thus attempts to use an
uninitialized stack. The notification callback is also modified to use
an RCU-aware list traversal.

For captures, the following field is added to struct lttng_ust_event_notifier:

       int eval_capture;                               /* Need to evaluate capture */

which is to be read once by the probe and its state saved and used
thorough the entire probe execution.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Iae70c5e7924f14b38e14676368cf2516951218ee