Fix CS handling, MFRC522 works again

Normally CS is asserted between messages then deasserted after the final
one. Setting cs_change to 1 deasserts CS between messages, but if set on
the final message it causes CS to remain asserted until the next transfer.
Counterintuitively, in the single message case, setting cs_change to 1
prevents CS from changing, while setting it to 0 allows it to change after
each message/transfer.

Some device, like the MFRC522 rely on a change of CS for synchronisation,
and you wouldn't want to leave multiple devices selected simultaneously,
so cs_change should be zero.

This issue was previously masked by the use of the BCM2835 hardware chip
selects, which don't allow CS to remain asserted between transfers.

See: raspberrypi/linux#1547
     #17

spi.c

@@ -186,7 +186,7 @@ static PyObject* transfer(PyObject* self, PyObject* arg)
 		.delay_usecs = delay,
 		.speed_hz = speed,
 		.bits_per_word = bits,
-                .cs_change = 1,
+                .cs_change = 0,
 	};
 
 	ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);