any valid stats reply message may have no entries

Section 5.3.5 of OpenFlow 1.0.0 specification tells:

"To ease implementation, the switch is allowed to send replies with no
additional entries. However, it must always send another reply following
a message with the more flag set."

The entry stands for an item of the array stored in the data field of
ofp_stats_reply structure body. This way the minimum required length of
an OFPT_STATS_REPLY message is 12 octets regardless of particular
statistics type. This was properly implemented for OFPST_FLOW (initial
commit), OFPST_PORT (commit 59f8403) and OFPST_QUEUE (commit 26d9b0a)
types, but the functions handling other statistics types assumed at
least one entry in the message.

In practice this caused an issue with a TableStatsRequest message sent
to a NEC PF5240 switch, which consists of multiple OpenFlow tables. The
OFPT_STATS_REQUEST message would be replied with a series of
OFPT_STATS_REPLY messages each with type set to OFPST_TABLE and flags
set to 1, containing a single entry for the respective OpenFlow table.
This series would be followed with a trailing OFPT_STATS_REPLY message
with type set to OFPST_TABLE, flags set to 0 and no entries. Trema
message validating code would react to the latter, sending an
OFPT_ERROR_MSG message and closing the TCP socket.

This commit fixes handling of the remaining (OFPST_DESC,
OFPST_AGGREGATE, OFPST_TABLE and OFPST_VENDOR) types so that the minimum
required length is 12 for all of them.