guidance on error handling/propagation of drivers

[rursprung]

trafficstars

since virtually all embedded-hal APIs are fallible (returning a Result) the question has arisen how drivers should return these to the caller when they don't deal with them themselves: should they propagate them upwards 1:1 or should they cover them in a generic "something went wrong" error? the former has the benefit that the caller of the driver could potentially try to rectify the situation if that were possible (how often is that the case?) but it has the downside of making the API a lot more verbose (presuming that the driver doesn't just have a single e-h error type to propagate up).

a concrete case where this came up is this PR: https://github.com/rust-embedded-community/tb6612fng-rs/pull/37

i think that there should be a general guidance for drivers on how to handle this (what was the reasoning behind the structuring of the errors in the current way?) which should be documented here, centrally.