Move error handling to messaging patterns

[glopesdev]

As described in #71, error handling is a growing concern for consistent implementation of Harp device interfaces. The new section introduced in this PR aims to provide clearer guidelines on how various kinds of errors should be handled and reported.

Closes #71

[glopesdev]

@bruno-f-cruz We could probably also resolve #55 in this PR. Leaving it here for discussion.

[bruno-f-cruz]

@bruno-f-cruz We could probably also resolve #55 in this PR. Leaving it here for discussion.

If the goal of "mute replies" is to stop any feedback from a command from the device, then I still think that suppressing the error response falls within this category.
My interpretation is that the error message is that it is still trying to fulfil the 1 request : 1 response contract. By enabling disabling this flag one would be instructing the device to explicitly NOT follow the contract.

[glopesdev]

By disabling this flag one would be instructing the device to explicitly NOT follow the contract.

Just to clarify, I'm assuming you mean here to set the flag. I'm fine with any interpretation, but I would be interested in hearing from @filcarv and @Poofjunior what exactly is implemented in core.atxmega and core.pico and whether both match this (and each other).

If not, we need to decide what to change to make things consistent.