LED API the sequel plus Makefiles

Basic api completed. Needs more formal testing (with more than 2 physical led matrices)

Note: this branch also includes work from dev/jpsnyder/debian. I merged it in to setup the setup.py and makefile to properly compile the led_driver extension. Through this, to install the package to the raspberry pi type in "make install" (provided you set up correct IP address)

It is now implemented with balance of python and c.  C (led_driver.c) is used mostly for managing the frame buffer and handling the generation of a bitstream from the framebuffer to be given to the spi port.  The python (led_matrix.py) is used mainly as a wrapper to call the correct led_driver functions plus some initial setup.

Two ways to initialize an led matrix: 

1.  call led2.initMatricies([ a list of tuples that define the matrix's offset in frame buffer (bottom left corner if using math coordinates, top left corner if using programmer coordinates) and the angle of rotoation (ie the way you will be holding it))])
 - the order of the tuples are the same order that the matrices have been physically hooked up in
  - for example: initMatrices([(0,0,90), (8,0, 180)])   this makes the first matrix at the origin but rotated 90 degrees and then the next is right next to it but rotated 180 (or 90 degrees with respect to the first one.
  - if the angle is not specified it is assumed to be 0 degrees. (for example [(0,0), (8,0)] for 2 matrices right next to each other)
  - led2.initMatrices() is equivalent to led2.initMatrices([(0,0)])



2.  call led2.initGrid(num_rows, num_cols, angle)
 - This is a wrapper to initMatrices that sets up the matrices in a grid pattern (the normal way you would set them up) without you having to figure out how to make the matrix list.

Once set up you can call normal command like point, text, line, sprite, etc..
A common convention in embedded systems for fixed sized global buffers that need to be available for the life of the program is to just make them global - that is no malloc.  Then they are automatically initialized to zero, there's no malloc failures to worry about, and no freeing.  The only issue is that you have to init them to their maximum size (but for embedded application, that's generally what you want).

Fine the way it is, fine to change it - doesn't matter.  Just wanted to mention it for future reference.