dev/pci: fix potential panic due to bogus VPD data

A panic has been observed on a system with a Intel X520 dual LAN
device. The panic is caused by a KASSERT() noticing that the amount
of VPD data copied out to the pciconf command does not match the
amount of data read from the device.

The cause of the size mismatch was VPD data that started with 0x82,
the VPD tag that indicates that a VPD ident follows, but with a length
of more than 255 characters, which happens to be the maximum ident
size supported by the API between kernel and the pciconf program.
The data provided did not resemble an actual VPD identifier, and it
can be assumed that the initial tag value 0x82 happens to be there
by accident.

An ident size of 255 far exceeds the sensible length of that data
element, which is in the order of at most 30 to 40 bytes.

This patch adds several consitstency checks to the VPD parser, the
most critical being that ident lengths of more than 255 bytes are
rejected. Other checks reject VPD with more than one ident tag or
with an empty (zero length) ident string.

This patch prevents the panic that occured when "pciconf -lV" was
executed on the affected system.

During the anaylsis of the issue and the VPD code it has been
found that the VPD parser uses a state machine that accepts tags
in any order and combination. This is a bad match for the actual
VPD data, which has a very simple structure that can be parsed
with a non-recursive direct descent parser (which always knows
exactly which token to expect next).

A review fpr a much simpler VPD parser that performs many more
consistency checks and rejects invalid VPD has been proposed in
review https://reviews.freebsd.org/D34268.

(cherry picked from commit f01c863337f7b097d03069daee359b6b5ecd0279)