gdbserver: fix unlikely getpkt buffer overflow

This problem was reported by Manish Sharma.

Within gdbserver, in getpkt, there is no bounds checking as we parse
the incoming packet.  An unexpectedly large packet can therefore
overflow the allocated buffer.  Fixed by adding bounds checking.

If a packet is too long then in ACK mode we send out the NAK, but then
immediately return -1 as the result from getpkt.  Currently the only
thing that GDB can do when it sees a '-' (NAK) is resend the packet.
If the original packet was too long then the resent packet will also
be too long.  gdbserver would then be stuck re-reading the incoming
too long packet.  Now GDB does give up after 3 retries, but this means
gdbserver is relying on GDB to give up sending, when in reality,
gdbserver knows it's not going to be able to recover.  So I propose
that gdbserver should just give up once it sees a packet that is too
long.

While looking at the error handling in this case I noticed that in the
noack_mode case, if we get a packet with a bad checksum, or a packet
that is too long, getpkt will return success and gdbserver will try to
interpret whatever it has.  This seems like a bad idea.  So I've
updated this code path to also return an error.

Then there are a couple of places where we had a comment like this:

  /* FIXME:  Eventually add buffer overflow checking (to getpkt?)  */

Now that getpkt does have buffer overflow checking, I've removed these
comments.

Approved-By: Andrew Burgess <aburgess@redhat.com>