Move all messaging patterns to device specification

[glopesdev]

As described in #71, error handling is a growing concern for consistent implementation of Harp device interfaces.

Remove ambiguous versioning string

This version string was already ambiguous and will be superseded altogether by tags in this repository.

Move error handling to messaging patterns section

The new sub-section aims to provide clearer guidelines on how various kinds of errors should be handled and reported.

Clarify rejection of register writes

Account for possibility to flag events as errors

In the near-future we may want to use this as an explicit exception
throwing mechanism used by the Parse operator.

Clarify error handling recommendations

Move messaging patterns to device specification

To further clarify and separate the specification of device operation
from the binary protocol, we move all messaging patterns to Device.md.

This greatly reduces the number of cross-references and duplicate
terminology across both documents.

Closes #71
Closes #55

[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.

[glopesdev]

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.

@bruno-f-cruz Indeed, I just tested this and at least on the ATXmega core, the error responses are indeed suppressed if the MuteReplies flag is set.

Interestingly, this also suppresses the reply to the OperationControl message itself that sets this flag. While I understand the logic that leads to this, one might want to know that the operation control was set, and not just lost. It is not crucial for now, but wanted to leave this observation here for future reference.