adding support for length prefixed json on the client socket

As @portertech & I agreed on IRC, I am adding support for length prefixed JSON to the client socket while keeping the existing behavior as it is.

Thanks,
praddy
1: Could you explain how that control flow works? As I'm reading the code, I can say I'm going to send 17 bytes, then I send `{"o hai": "data"}XXYZZYXX`, (25 bytes) then the code extracts the first 17 bytes and everything's dandy. The code disregards the fact that there's 8 bytes of inexplicable extra tacked on the end.

2: There's already the `ping` opcode.

3: The overhead of doing an MD5 (or CRC-32, even the moreso) check is a triviality when each one of these connections already requires a TCP session setup and tear down in order to publish check results (I'm ignoring UDP because I can't think of a case where randomly dropping check results is an acceptable design feature). And since most of these connections are happening over localhost, it's unlikely that sensu would ever see the connection volume that would have an MD5 checksum computation be a bottleneck compared to, say, JSON serialization and deserialization overhead. So I'd say performance can be set aside as an argument. The point is to detect and fail explicitly for a certain class of error (the data sensu received is not what the sender intended) instead of admitting that broken input and hoping some other component catches the error as a side effect. I say all of this because at this point I've wasted a good 12 hours over the past six months tracking down problems with Sensu or its ecosystem that boil down to things blindly accepting detectably-bad input and failing silently.