Fix: use the same actions to compute event size and to serialize

Fix: use the same actions to compute event size and to serialize

Issue
=====
In `gen.py`, the code to generate the event size computation C code and
the event serialization C code are not the same. There are optimizations
to avoid generating useless alignment statements in one which are
missing in the other, and those optimizations have a bug. This bug can
lead to the space reservation phase of a tracing function passing
(enough space for a given event to serialize), but the serialization
phase writing passed the end of the packet buffer.

Solution
========
Make barectf use the exact same actions to generate the event size
computation C code and the event serialization C code.

In `gen.py`, `_SerializationActions` is a new class of which you can
use an instance to append a root scope field type
(_SerializationActions.append_root_scope_type()) and to retrieve a list
of resulting serialization actions. The two types of serialization
actions are:

`_AlignSerializationAction`:
    Force the alignment of the current bit position within the packet.

`_SerializeSerializationAction`:
	Serialize a field from a given type.

Each action object contains:

* An optional field type which is responsible for the action.
* An offset within the current byte when this action needs
  to be executed (to generate the appropriate bt_bitfield_write_*()
  calls).
* A list of names which identify this action (complete field name/path).

_SerializationActions.append_root_scope_type() performs the necessary
optimizations (does not align when specific conditions are met to avoid
a useless alignment statement). Then those optimizations apply to both
the event size computation and event serialization C code, the only
difference being that the event size computation code adds to a partial
sum variable instead of writing to the packet buffer.

The alignment optimization technique is straightforward at this point
and could be improved: if the alignment requirement did not change since
the last alignment, and if there's no padding between a field and the
previous field, then do not align for this field; otherwise, align.

Known drawbacks
===============
Because the alignment optimization technique is changed to be simpler,
some barectf configurations could make barectf generate more C code
(which means more compiled code and slower execution eventually).
However, the previously generated C code was incorrect anyway.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>