`1-wire` API

Start by reviewing issue #29, the Maxim 1-wire bit-banging references, and the existing embedded-hal trait scope. Define what belongs in the master API versus device drivers, including CRC and device search, and resolve whether slave support and blocking timing are in scope. Done means the API scope and timing model have been agreed before implementation begins.

I'd like to propose a trait for a bit banged 1-wire protocol.
It is a fairly simply protocol that uses a single pin for communications between one master device and many slaves devices. Because of this #29 is currently a blocker.

The protocol for a master device itself primarily consists of the following:

• It has two different speeds, "standard" and "overdrive" hence the two different timings
• Write a 1 bit by pulling the IO low for either 6us or 1us
• write a 0 bit by pulling the IO low for either 60us or 7.5us
• read a bit by pulling the IO low for 6us or 1us and then reading the IO 9us or 1us later
• reset all devices on 1-wire bus by pulling the IO low

There is some other common functionality that afaik most 1-wire devices use (CRC, a sort of binary search to identify all of the devices on one bus, etc). I haven't worked with 1-wire enough to know what all should be included in the embedded-hal API vs in a device driver. I think the CRC, search, and a couple of other things should probably go in embedded-hal.

I'm not sure it is worth implementing both master and slave APIs. I've only seen a few projects implement a slave in software since it has some pretty big drawbacks. It would have to be either an interrupt driven API or would have to continuously poll the IO pin. Thoughts on this?

Since this is a bitbang protocol and we are doing all of the timing in software it might need to block in some of these functions. Admittedly the timing has fairly loose requirements, but I'm not sure how well using the nb crate here to prevent blocking will work across different speed embedded devices (e.g. using yeild/generators on a fast STM32 vs on a atmega328). @tib888 wrote an implementation of 1-wire for RTFM using atomic blocks to handle this.

I'll start working on an example trait and implementation for this next week, but I want to see what sort of scope embedded-hal will have with regards to the extra functionality and I'd like opinions on the timing/blocking issue.

Some references:
Maxim app note on bitbanging 1-wire: https://www.maximintegrated.com/en/app-notes/index.mvp/id/126
Maxim app note on the search algorithm: https://www.maximintegrated.com/en/app-notes/index.mvp/id/187
Some more indepth info on the protocol timing: https://www.maximintegrated.com/en/app-notes/index.mvp/id/74