FAST: Introduce XML templates

It's quite usual to distribute FAST templates as an XML files. It's a
good idea to support them in a library.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Sequence support introduced

The patch implements FAST Sequences' support.
The following features are valid:
* Sequence decoding engine
* Sequence xml parse engine
* Sequence message's formatted output

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: function to reset a message is added

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Save a template id of the last parsed message

If a FAST message being parsed does not contain an explicit
template id declaration the previous one should be used.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: fill rx buffer with data once it is empty

Here is the way we parse incoming FAST messages now.
We are decoding the message field by field and if
the buffer is empty at some moment we actually perform
three steps: a) we move buffer's start pointer to the
beginning of the FAST message b) we fill buffer with
data and c) we try to parse the message again
starting from the very first field. This approach is
erroneous because once a particular field is parsed
it might change its value or state. The FAST parsing
result depends both on the incoming data and the
field's current state. Once the state is changed
the parsing result altered also which could lead to
incorrectly parsed message.

To cope with such a problem a modified approach is
proposed. If a particular field is unable to be
parsed we do not wait until we have another chance
to do that. Instead we try to fill the buffer with
data immediately.

A few additional moments are worth to be mentioned:
a) rx buffer's size must be at least 2 * FAST_MESSAGE_MAX_SIZE
b) If you take a look at data_read() code you might notice that
we are reading FAST_MESSAGE_MAX_SIZE from the socket no matter
how many bytes we actually need. This is done on purpose.
The fact is that a lot of FAST messages are distributed via
UDP datagrams which makes us impossible read a part of
the datagram without losing the remaining part. So, actually
we need to read not a FAST_MESSAGE_MAX_SIZE but the maximum
datagram size. Please, let me know if you have an idea how
to workaround it smoothly.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: a testing interpreter application is added

A testing application is added. It just joins a UDP multicast group,
gets the incoming FAST messages, parses them and printing out the parsed
result.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Merge branch 'marat'