This should resolve the issue reported in #867 that when running
setup.py install (and in particular when installing Astropy with pip)
the ~/.astropy directory gets generated, when really it shouldn't be.
This commit does a few different things:

 * I've never been too thrilled about having code that can modify the
   system at import time. In the case of generating the default
   astropy.cfg and log I think we have a reasonable excuse, but let's
   try to keep stuff like that in astropy/__init__.py: For that reason I
   moved the logger module initialization code to an `_init_log()`
   function which is called in ``astropy.__init__``.  I also set up a
   default dummy-log so that stuff like ``from astropy import log`` will
   always work even if the real logger hasn't been initialized.

 * For the default config generation I got rid of the environment
   variable hack and just set ``_ASTROPY_SETUP_`` when running the
   subprocess.

   * This requires changing the imports that are only performed when
    ``not _ASTROPY_SETUP_`` to be at least attempted, and only raise an
    exception if we're not in setup mode (this way when the default
    config generator gets to those imports they will still work).

 * Ensured that no attempt is made to create a config file if
   ``_ASTROPY_SETUP_``.
This should fix the problems on Python 3. This forced me to finally go through much of astropy.io.fits and make it at least *importable* under Python 3, since the only places the wcs module was having issues was where it imports from io.fits.
A few more syntax fixes in io.fits for Python 3. These are easier to make in Astropy than in pyfits, which still supports Python 2.5
Merge pull request #867 from iguananaut/issue-867

pip install problem - owner of .astropy is root