src: enable 12 channel operation, still buggy

Only 1 slave works right now. It is obvious that waiting for a slave OK
indefinitely is not good. Commit this as a safe point.
src: rename input_nopullup() to input_hiz() in iocontrol.h

Inputs without an enabled pullup are Hi-Z inputs (this is the default).
Rename function in iocontrol.h accordingly.
src: 3 slaves can now be addressed separately (READ LONG DESCRIPTION)

Slaves' OUT OK lines were "multiplexed" lousily. In fact, they were not
multiplexed at all, just three output lines hooked up to the same physical
line. This might have created logic glitches, so we now have three separate
physical lines, one for each slave. So two more pins ar used on the master.

These are on port D (pins D3 and D4). The earlier OUT OK line was (and
still is, for slave 1) on port C pin 0.

There is a new function slave_is_available() which takes one uint argument
and returns 0 or 1. For the master, OUT OK lines are connected to inputs
with pull-ups. So if the slave is disconnected, there is a logic 1 on the
line, and slave_is_available() returns 0. If the slave is available the
line will be logic 0. Slave-side, a 0 is set as a default in
spi_slave_init(). It is also set to 1 inside an interrupt which is
triggered by master's SLAVE SELECT. When master sees this 1, he transfers
data. Slave sets the line back to 0 before exiting its interrupt routine.

There is still some bug, though, don't know if software or hardware. If
only one slave is physically connected to the master (and feeds it power,
too), then everything works fine. Master receives DMX data and relays the
appropriate 4 channels to the connected slave, skipping the other two
(unconnected) slaves, because their OUT OK lines show 1 (and
slave_is_available() returns 0, meaning slave is not available).

However, if more than one slave is connected, there is trouble. Master
normally iterates over all 12 channels, first checking if the appropriate
slave is available, then if there is new data for that channel (perhaps
this should be the other way around, will try). If both are true, Master
branches into the data-sending block. He sets the channel using
spi_chan_select(), sends an interrupt with spi_request_interrupt(),
and seemingly gets stuck checking slave_is_available().

This means either slave_is_available() has a logic bug, or there is a
hardware bug (or both, or something else entirely).

There is debug code scattered all over, but mainly in master.c:

148         // wait till slave says OK (marks itself busy/unavailable)
149         led_on(0);  // debug
150         if (c == 11) led_on(1);
151         while (slave_is_available(c/4));
152         if (c == 11) led_off(1);
153         led_off(0); // debug
154
155         // transmit channel's value
156         retval = spi_master_transmit(chanval);

When moving slider 1 (channel 1, slave 1, slave channel 1, c=0), only
the red (0) led lights up, and Master's program gests stuck inside the
while loop, no longer responding.

When moving slider 12 (channel 12, slave 3, slave channel 4, c=11), both
leds light up (0=red, 1=green), and the Master is stuck.

Also, Slave is toggling its green led when receiving this data interrupt.
When only one slave is connected, it is possible to toggle this led just
once by sending appropriate DMX data (e.g. change channel value from 0
to 1). With more slaves connected the led seems to blink - probably once,
i.e. two interrupts are received.

This is where a logic analyzer would have been handy.

Perhaps my layout for a shared SPI bus is borked?..