Suggestion: Avoid `ErrorType`

[madsmtm]

trafficstars

I agree that the ErrorType trait is somewhat useful, motivation here, but I think that it may actually in most cases be detrimental to the API?

In each of the cases where it is currently used, I think there is a better pattern to use instead, that will be simpler for users to understand, easier for implementers to use, and more flexible and correct.

Let's consider the modules one at a time:

• embedded_hal::digital: ErrorType should be renamed Pin since that is what it logically represents (it is a supertrait of InputPin and OutputPin).

• embedded_hal::i2c: ErrorType should be removed, and the associated Error type should be moved to I2c.

  The downside is that now the error type is no longer shared between the blocking and the async version, though I believe this tradeoff is worth it, since it is very rare that you'd be working with both traits at the same time.

• embedded_hal::pwm: ErrorType should be removed, and the associated Error should be moved to SetDutyCycle (unless you have other plans for extensions to this module, then it may make sense to rename the trait to Pwm or similar instead?)

• embedded_hal::spi: Unsure about this, pending discussion in https://github.com/rust-embedded/embedded-hal/issues/525.

• embedded-io: More unsure here, but I suspect the ErrorType design is also the wrong design here: an implementation of Read should be allowed to have a different error type from Write, even though it may be a bit more hazzle to work with types that are Read + Write (users would have to write <T: Read<Error = E> + Write<Error = E>, E> if they wanted to force the same error type).