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. Although it
could happen, depending on timing conditions caused by exchange of other
OpenFlow messages, that a few TableStatsReply messages were delivered to
the Controller class instance, the message validation code would
unavoidably raise an error condition and close the TCP session as soon
as it met the trailing OFPT_STATS_REPLY message without a statistics
entry.

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.
Merge pull request #235 from infrastation/develop

this fixes a bug with a NEC switch