Rearranged CompImageHDU._prewriteto and _writedata_internal to replace the .data attribute with the compressed data sooner in the writing process.  This prevents an unncessary decompression that was occurring when writing an otherwise unmodified compressed HDU to a new file.  This also required refactoring BaseHDU._prewriteto by breaking its functionality up into separate _update_uint_scale_keywords and _update_checksum methods.  This had the added benefit of making it easy to add correct support for (at least writing) checksums for compressed images.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2269 ed100bfc-0583-0410-97f2-c26b58777a21
Changed the behavior of the internal HDU property `_data_loaded` so that
it returns True even if `self.data is None`.  Sometimes it's useful to
check if the HDU's data has been read/processed/replaced even if its
currently value is now `None`.  Added a new property called `_has_data`
with the same behavior as the old `_data_loaded`.

This had some surprising side-effects: in the `._summary` method of some
of the HDU classes there was a check that previously could never passed
(because it required `self._data_loaded and self.data is None` which was
previously impossible) that returned an array's format string as an
empty string if contains zero data.  Making this change caused that test
to start passing and changed the output of the `pyfits.info()` function.
I thought this new behavior seemed reasonable so I decided to change the
tests and not keep the old behavior.  But I needed a few additional
tweaks (especially in GroupsHDU) to make sure the new behavior applied
consistently.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2272 ed100bfc-0583-0410-97f2-c26b58777a21
This change resolves an issue where table data was unnecessary read from
a file and/or put through a time-consuming processes of checking to see
if each column needed to byteswapped, even if the table data was
completely unmodified.  Furthermore, the byteswapping code had a bug
where it could cause the heap data for VLAs to be rewritten, but in the
wrong order.  This bug is difficult to write a test for within pyfits
because the way pyfits writes VLA columns it never interleaves the heap
data for two columns.  I have a sample file that is written in such a
manner, however, and this change was able to fix issues with writing
compressed data from that file to a new file.  Still, before I can call
this issue 100% fixed I will try to contrive a test that exhibits the
problem.

This added a simple method for copying data direct from one file to
another, and without reading the source bytes entirely into memory first
(which is the old behavior--probably required an inordinate amount of
memory to be used when writing files in certain circumstances).

This also required finally adding a `._data_needs_rescaling` attribute
on ImageHDUs to clarify up front, even before an image's data has been
read/rescaled, that upon writing to a new file the data *will* need to
be rescaled (see track issue #101 and friends).  Later a similar
attribute will need to be added to table HDUs, but only once the PR for
scaling table columns has been merged (there is one such fix in
progress).

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