Implemented InputPin trait for output pins

[David-OConnor]

This enables things like OneWire. Equiv of this PR from the 4xx lib.

[jeru]

+1. I also need this functionality, to implement a weird "bidirectional" SPI for ST7735 TFT.

And it is already implemented in the "brother" crate stm32f4xx-hal (https://github.com/stm32-rs/stm32f4xx-hal/blob/b6f010538a4f86db207b23440d3053339ce08397/src/gpio.rs#L179).

[David-OConnor]

Status? This is the sort of functionality that is required to support a relatively-common protocol, and ommitting it fragments the ecosystem with people using forks etc instead of crates.io.

[Sh3Rm4n]

Sorry for the long delay. I'll hope to catch up again in the next days :)

What about this concern: #84 (comment)?

I havn't thought it through myself. Implementing for OpenDrain seems fine though. Maybe we could mark the PushPull implementation unsafe or at least add a comment to use this function with caution.

[teskje]

Please run rustfmt on the code again. It's currently complaining about one superfluous newline. This is what makes the Travis jobs fail.

[teskje]

I also noticed that since the GPIO refactoring to use variants was merged, this should also be adapted in this PR. I've quickly done this myself, hope you don't mind me going off your changes @David-OConnor.

I had to create a new PR since I cannot just push to a branch in your repo: #114. Would be cool if you could check it out and report if it works for your use-case. You'll notice that I restricted the InputPin impls to Output<OpenDrain> only, based on what was discussed in #84. Looking at the onewire lib they are using OpenDrain too, so that shouldn't be an issue.

[teskje]

Closed in favor of #114.