Gracefully handle errors when decoding encapsulated commands

[Ben Youngblood]

Summary

Currently, an error encountered while decoding a Z/IP Packet's encapsulated command results in a raising a MatchError here: https://github.com/smartrent/grizzly/blob/main/lib/grizzly/zwave/commands/zip_packet.ex#L83. The resulting exception should (hopefully) include the parameter and value that failed to be decoded, but the rest of the message binary is important context we don't want to lose.

---

To address the immediate issue, let's add a cause field to Grizzly.ZWave.DecodeError. When decoding something that can itself return a DecodeError, the original DecodeError should become the cause of the new one to maintain context.

For decoding errors that occur via a call to Grizzly.send_command/4, we should continue to raise in order to preserve the current behavior.

For the decoding errors encountered in the unsolicited server, we should add a new Grizzly option that allows consumers to pass in an error handler function. If provided, the unsolicited server will report decoding errors to that function. If no function is provided, the unsolicited server should instead log an error with as much detail as possible.