Starting work on muonlab with pylibftdi

Ouch!  Many lockups of keyboard and touchpad later, I found out that
libusb on OS X does not work as advertised.  However, the fork libusbx
*does* work correctly.  Pfew!  However, I still don't really have a
feeling for pylibftdi...  Here's hoping that it is more stable and
user-friendly than pyftdi!
Created a setup.py, so tests can import modules
Started work on MuonlabII class, with tests
Utility functions to map a value to a byte or word value
Added set pmt voltage and threshold to muonlab ii class
Implemented muonlab II measurement modes
Read lifetime data
Cleanly shut down muonlab hardware on exit
write_setting is now a private method
Added method to flush device
Added read coincidence data method
Defined some constants and cleaned up bit operations
Added example/test scripts
PEP 8 fixes
PEP 257 fixes
Added muonlab II configuration class
Revert "Added muonlab II configuration class"

This reverts commit b1ed0cb619f2b4b3e6fa4626d29fbdf1fce9f13a.

I'm headed towards writing a very tightly coupled configuration class.
I'm not sure what to do.  I'd like to have the ability to do something
like::

    >>> muonlab.pmt1_voltage = 900

but then I'm mixing the muonlab object with a muonlab data structure.  So,
I wanted to split out the data structure as a configuration class, like
so::

    >>> muonlab.config.pmt1_voltage = 900
    >>> muonlab.read_lifetime_data()

This is better.  However, the config class needs to call
muonlab._set_pmt1_voltage(), etc.  Tight coupling.  Alternatively, the
_set_pmt1_voltage code can be moved into the configuration class, but then
the configuration class knows even more about the muonlab hardware.  Sigh.
Hardware setting methods now public
Select a measurement mode, not set it
Updated example scripts