in_s3: stop retrying SQS messages that can never succeed

[Watson1978]

Posting hello to the queue is enough to stall an in_s3 source for up to 14 days. Every per-message failure becomes :skip_delete, so SQS redelivers the message after the visibility timeout, it fails identically, and this repeats until the retention period expires — burning CPU, log volume and SQS requests with nothing ever ingested. skip_delete is false by default, so anything that can put a message on the queue can trigger it, and a corrupt or unparsable object does the same once fetched.

• Name the errors that no redelivery can fix — a body that is not JSON, an archive zlib rejects, bytes the parser cannot read — and delete such a message instead of retrying it forever. The list is the plugin's own: it overlaps with the one Fluent::Plugin::Output keeps for its retries, but an input plugin should not depend on where an output plugin draws that line
• Leave NoMethodError out of that list: it is more likely a defect of ours than a property of the message, and stalling the queue beats turning our own bug into lost notifications. get_raw_key now uses dig so a malformed body yields nil rather than raising it
• Keep every other failure on :skip_delete, so a networking error, a throttle or a missing object is still retried, and a redrive policy with a dead letter queue stays the tool for capping that
• Name the object key in the warn that deletes, truncated to 256 bytes and scrubbed, because that line is the only record the object leaves behind, and log the backtrace there too since our own bugs reach the same path
• Raise an unrecoverable CommandError when an extractor command exits non-zero, but a plain error when the process was signalled, and let it out of the lzo, lzma2 and gzip wrappers, whose "Failed to extract #{path}" named a local of extract_with_command and raised NameError over the real cause
• Document in docs/input.md which failures delete the message, so that a conservative decompression_size_limit is not chosen without knowing it discards notifications

in_s3 tests go from 46 to 81, covering both sides of the boundary and locked with a mutation pass. Parser exceptions outside MessagePack::UnpackError, such as CSV::MalformedCSVError, are left for a separate change. Two pre-existing limitations are unchanged: only Records[0] is examined, and add_object_metadata reports the URL-escaped key.

[Watson1978]

Thanks