Proposed rewrite of iic(4)

[Jason Harmening]

Hi everyone,

I am attempting to tackle the big issues with iic(4)...the limitations on
read/write length, the limit of only one open fd at a time, and the need to
issue I2CSTART before read(2)/write(2) can work.
I want to do this in a way that doesn't break existing applications such as
i2c(8).

Along with that, I have some fixes for iicbus_request_bus() and
iicbus_release_bus():
--right now, iicbus_request_bus() can fall through and succeed if the
requesting device already owns the bus, making it "device-recursive" if you
will.  Having multiple threads on iic(4) wouldn't work with that scheme,
and it is also problematic because iicbus_release_bus() is not
device-recursive.
--if the call to IICBUS_CALLBACK in iicbus_request_bus() fails but the
following call to iicbus_poll() succeeds, then IICBUS_CALLBACK won't be
called again
--Holding the iicbus mtx across IICBUS_CALLBACK seems dangerous.  In fact,
it looks like there are several drivers that could have issues with that:
   --lpbb and gpioiic can sleep in their IICBB_CALLBACK if IIC_WAIT is
passed
   --bktr/bktr_i2c.c grabs Giant in its IICBB_CALLBACK, which can sleep and
also seems prone to LOR if the iicbus mtx is held.

The review is at https://reviews.freebsd.org/D2140 if you want to chime in
and poke holes :)

--Jason