Fix: reloc offset validation error out on filters with no reloc table

Fix: reloc offset validation error out on filters with no reloc table

The reloc table is currently appended at the end of the bytecode data.
With this scheme, the reloc table offset will be equal to the length
of the bytecode data.

<- length ->
+----------+-------------+
| BYTECODE | RELOC TABLE |
+----------+-------------+
           |
           +--> Reloc table offset

A special case arise with filters with no reloc table.

Example:

Filter: "myString" == "yourString"
./filter-grammar-test -p -B -i -b < bogus
<root>
        <op type="==">
                <expression>
                        <string value="myString"/>
                </expression>
                <expression>
                        <string value="yourString"/>
                </expression>
        </op>
</root>
Generating IR... done
Validating IR... done
Generating bytecode... done
Size of bytecode generated: 24 bytes.
Bytecode:

Val. Operator
---- --------
0x40 (FILTER_OP_LOAD_STRING)
0x6D m
0x79 y
0x53 S
0x74 t
0x72 r
0x69 i
0x6E n
0x67 g
0x00 \0
0x40 (FILTER_OP_LOAD_STRING)
0x79 y
0x6F o
0x75 u
0x72 r
0x53 S
0x74 t
0x72 r
0x69 i
0x6E n
0x67 g
0x00 \0
0x0C (FILTER_OP_EQ)
0x01 (FILTER_OP_RETURN)

Reloc table (offset: 24):
Empty

<-   24   ->
+----------+
| BYTECODE | <- No reloc table
+----------+
           |
           +--> Reloc table offset

In this case, we see that the reloc table offset (24) is indeed equal to
the length of the bytecode (24), but the reloc table is _empty_. Thus,
the reloc_offset received in handle_message() will be equal to the
data_size and will be wrongly flagged as not within the data even thought
the filter is entirely valid.

The fix is to simply allow a reloc_offset to be equal to the data_size.

Fixes #342

Signed-off-by: Christian Babeux <christian.babeux@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>