Static-ize a private function
Re-add analysis code

Note that it currently does not build. This is a checkpoint commit.
[analysis] Link statically against the lib

The shared object of the s7 lib deliberately hides its internals,
exposing only the minimal number of functions required to actually use
it. This is intended to make maintaining the API easier.
It's not so great for the analysis code, which wants to play with the
internals of the lib (i.e. use ppkt structures and use only selected
protocol layers).
[analysis] Re-introduce the pcap layer

It currently calls back into the analyze_pcap_receive() function, which
doesn't do anything.
[ppkt] Allow ppkt_chain_size() on NULL

Allow users to call ppkt_chain_size() with a NULL ppkt. This doesn't
make much sense at first glance, but it's a usefulf shortcut for the
layers which accumulate data until sufficient bytes are present to
process a header.

It allows them to do while (ppkt_chain_size(queue) > ...) rather than
having to explicitly check for NULL as well.

Consider a NULL pointer to be a chain of lenght zero.
[tpkt] Keep processing as long as there's enough received data

Sometimes the tktp_receive() callback receives data for multiple tpkt
packets.

We have to keep processing the new data until there's not enough for a
full tpkt packet (with payload).
Move the TPKT port number to the tcp file

Remove all knowledge of the TPKT port number from the tpkt layer and
move it all into the TCP layer.

There's no real reason we need to support different port numbers.
RFC1006 specifies port 102 and it's unlikely we'll ever see a PLC using
a different port number.

The biggest advantage though is that it means the arguments for
tcp_connect() are now the same as for all the other protocol layers.
[build] We use CXX so define it explicitly in vars.mk

This is not a functional change, but it's clearer this way that we
do use CXX in some places.

(It's used to link the unit tests, which use CppUTest.)
Loosly couple the protocol stack

Previously each layer of the protocol stack (TCP|TPKT|COTP|S7COMM) had
no knowledge of the protocol 'above' it but was tightly coupled to the
lower layer protocol (i.e. TPKT knew nothing about COTP but did know
TCP).

That works OK, but it makes life hard for the analysis code, which might
want to handle only single layers of the protocol.

Here we try to break the tight coupling to lower layer protocols by
introducing struct proto_t, which defines all operations exposed bby a
given protocol. It should let us stack the protocol layers in
essentially arbitrary combinations (within limits, s7comm must always be
a top layer protocol and tcp/pcap must always be bottom layer
protocols). This should allow the analysis code to hook in at any level.
[analyze] take advantage of the loose coupling in the protocol stack

We can now create a tpkt layer and explicitly instruct it to use pcap as
a lower layer.
Protocol stack support

Rather than supplying only the underlying protocol to a protocol layer
supply all of the underlying layers. This allows us to define arbitrary
stacking of protocols, and lets the analysis code hook in wherever it
likes.