DEP: drop runtime dependency on setuptools

[neutrinoceros]

Description

This is a follow up to #2365
At the moment this breaks tests because mpl-scatter-density has an undeclared runtime dependency on setuptools
(addressed at astrofrog/mpl-scatter-density#43)

I also note that the following comment

glue/glue/main.py

Lines 75 to 87 in e9df453

	# We don't use item.load() because that then checks requirements of all
	# the imported packages, which can lead to errors like this one that
	# don't really matter:
	#
	# Exception: (pytest 2.6.0 (/Users/tom/miniconda3/envs/py27/lib/python2.7/site-packages),
	# Requirement.parse('pytest>=2.8'), set(['astropy']))
	#
	# Just to be clear, this kind of error does indicate that there is an
	# old version of a package in the environment, but this can confuse
	# users as importing astropy directly would work (as setuptools then
	# doesn't do a stringent test of dependency versions). Often this kind
	# of error can occur if there is a conda version of a package and an
	# older pip version.

which was introduced in #1487, has been irrelevant since #2365 (at least in part) since it mentions behavior details that were specific to setuptools. Should this comment be removed entierely or just rephrased ?

[astrofrog]

Just a small comment below. Otherwise, regarding the comment about not using item.load(), are you sure that these kind of errors should not happen anymore? If not, then in addition to removing the comment we should then actually use item.load() below in the try...except?

[astrofrog]

I'd like to keep 'Loading external plugins' - just don't give the setuptools version

[neutrinoceros]

are you sure that these kind of errors should not happen anymore?

I don't know if there's a test to exercise this condition, but I tried replacing module = import_module(item.module) with module = item.load() and found it broke some tests for a different reason: EntryPoint.load doesn't always return a module, which is actually documented in this function's docstring:

        """Load the entry point from its definition. If only a module
        is indicated by the value, return that module. Otherwise,
        return the named object.
        """

so it stills seems simpler/safer to use import_module here, but I think we should update the comment to reflect the real reason. Should I do it here ?