I got a traceback this morning when trying to run Astropy's setup.py (in order
to try to reproduce #452).  Instead I got something unrelated:

```
Traceback (most recent call last):
  File "./setup.py", line 25, in <module>
    from astropy import setup_helpers
  File "/bray/sc1/root/src/astropy/astropy/astropy/setup_helpers.py", line 196, in <module>
    from sphinx.setup_command import BuildDoc
  File "/bray/sc1/root/home/embray/.virtualenvs/astropy-dev-27/lib/python2.7/site-packages/sphinx/setup_command.py", line 20, in <module>
    from sphinx.application import Sphinx
  File "/bray/sc1/root/home/embray/.virtualenvs/astropy-dev-27/lib/python2.7/site-packages/sphinx/application.py", line 21, in <module>
    from docutils.parsers.rst import convert_directive_function, \
  File "/bray/sc1/root/home/embray/.virtualenvs/astropy-dev-27/lib/python2.7/site-packages/docutils/parsers/rst/__init__.py", line 75, in <module>
    from docutils.parsers.rst import states
  File "/bray/sc1/root/home/embray/.virtualenvs/astropy-dev-27/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 108, in <module>
    import roman
ImportError: No module named roman
```

The problem is that if importing sphinx fails it should be ignored, but if any
other ImportError occurs in the *process* of importing Sphinx it is raised.
There are a couple problems with this.  First of all searching for the string
`'sphinx'` in `e.args[0]` is an unreliable way to determine anything about an
ImportError (in fairness, there really is no good way prior to Python 3.3 which
finally fixed that wart).

Second of all, what actually happened here is that there's something broken
about my docutils installation.  Having a broken docutils or sphinx
installation should NOT cause Astropy installation to fail, since it's not even
necessary except for building the docs.  Allowing an error to be raised here
could easily lead to confusing, difficult to reproduce bug reports since it was
something broken in my setup, and nothing to do with Astropy.
Fixes #452. Don't assume the 'run' method is a direct member of the class, and not inherited through a parent class.  In fact, don't assume that a run method already exists at all (though it really always should if it it's a distutils command).
Clarified a comment
Instead of wrapping the entire AstropyBuildSphinx definition in a try/except block, add a HAVE_SPHINX global variable a la HAVE_CYTHON; put the AstropyBuildSphinx definition in an if statement instead.
Followup to 7f85b89, where AstropyBuildSphinx is no longer defaulted to None if sphinx failed to import.  This is more consistent with what we do with Cython.
Make sure all sphinx-related imports are working before trying to do anything with sphinx.
Fixed some potential NameErrors that could occur in edcffac.  I preferred importing BuildDoc as SphinxBuildDoc, because it just makes it more clear where that class is coming from.
Merge pull request #452 from iguananaut/issue-452

Build failure in build_ext
Merge pull request #453 from iguananaut/fix-setup-sphinx

Don't raise internal ImportErrors from import sphinx
add open-docs-in-browser sphinx_build option
fix for more cross-platform urls
Merge pull request #455 from eteq/docs/open-in-browser

add open-docs-in-browser sphinx_build option
Merge branch 'master' into vo-conesearch
added vo.server codes