Justin Ely pointed out a regression where previously it was possible to pass in something like format='f4' to the Column initializer, indicating that a single precision float column should be created (presumably for a binary table, at least by default).  The fact that this even worked before only further compounds the confusion over the 'format' argument, but I didn't intend to cause a regression on this behavior, and who knows how much code is out there that depends on it.  This adds still more sophistication to the column format guessing scheme, and fixes a few other issues that arose when I wrote regression tests covering the previous behavior.  This also reverts the change I (likely sleepily) made to the tests in 43c6162c48083fbf1d48757849da588348df6ab3, which allowed binary tables to be written with format codes for character columns like 'A10' (for 10 character strings).  The proper format, per the FITS standard, should always be '10A'.  Although the Column constructor allows both forms, only the '10A' form should be written.  I couldn't find *any* FITS documentation suggesting flexibility in this matter (the closes I could find is the substring array convention: http://fits.gsfc.nasa.gov/registry/substring.html, but that has never been supported by PyFITS).

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2345 ed100bfc-0583-0410-97f2-c26b58777a21

Conflicts:

	astropy/io/fits/tests/test_table.py
Added documentation for the new support of pseudo-unsigned integer columns to the changelog

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2346 ed100bfc-0583-0410-97f2-c26b58777a21
Merge pull request #1770 from embray/fits-merge

Fix for regression in pyfits on column format support