Refractor use of __init__ in io.ascii Readers

In the Readers, ther eare two ways how parameters are set.
Either they are defined in the header or data objects like this:

Method I:

class MyHeader(BaseHeader):
    comment = r'\ #'

of in the __init__ of the Reader, such as this:

Method II:
class Reader(BaseREader):
	def __init__(self):
		self.header.comment = r'\ #'

The first method makes it easy to derive from that class, the second method
makes it hard. This PR aims to transfer has much as possible from the
second method to the first. However, sometimes that's not possible
because a values are only given at runtime. Again, there is two ways for that:
1) in the __init__ such as
def __init__(self, definition='ignore', DBMS=False):

2) using the ui, such as
table.read(delimiter='%')

Back to Method I vs II:
In a class hirachy, once one class sets a value in __init__
all derived classes have to do the same, because their class attributes
will get overridden once __init__ is run.

This PR transfers a set of things from method II to I.

Does this break the API?
------------------------
If somebody derived from class in the way we used to do
(Method II was used almost exclusively) in the package: No.
If someone used Method I in class where io.ascii uses Method I: No change,
since the derived method sets the class attribute.

If someone set a class attribute, but that did not take effect because it was
overridden in one of io.ascii's __init__ methods: Yes. However, in that case
that's a bug that we fix and not an API change. If a derived class
specifically sets a value, then that value should NOT be overridden.

Is this complete?
-----------------
No, because in some cases Method I is not practical or requires the
definition or a new Data class. I think we should still do that, but I want
to run it through Travis first (tests pass locally).

Also, I have changed calls to Baseclass.__init__ -> super(Class, self).__init__
Strictly speaking this change is independent of the main goal of this PR,
but I decided to follow the astropy coding guidelines here because
(a) I had to touch all the __init__ calls anyway
(b) I have changed one or two Base classes. Using super() I don't have to
care, while I would have to be more careful with direct calls to
BaseCalss.__init__(self).

This is a partial answer to #2810
io.ascii Readers now use __init__ only to set keyword arguments
Use class attributes correctly in HTML Reader instead of __init__
Try to fix sphinx errors after defining new classes
Import entire tree of inheritance in astropy.io.ascii

In the current setup, not every class in io.ascii is documented, but only
those that are part of the top-level namespace io.ascii as defined in
io.ascii.__init__

For every class in there, sphinx sets links to the parent class. Thus, for
every class in this list, all parent need to be in this list, too.
This commit adds BasicData and BasicHeader, which are parents of
FixedWidthHeader and FixedWidthData, respectively.

Implement changes from PR discussion, mostly in ascii table reader docs
Simplify changelog entry for #2812
Initial drop of support for Python 3.1 and 3.2, including removal of several hacks specifically for supporting those versions (this is probably not exhaustive, but the others can be removed when found).  Drop 3.2 from travis builds and 3.1 and 3.2 from tox.ini.
Fix typo in construct_table.rst
Merge pull request #2851 from larrybradley/patch-1

Fix typo in construct_table.rst
Merge pull request #2812 from hamogu/subclassreader

Simplify creating derived Readers by using class attribute inheritance
Merge pull request #2018 from embray/misc/pyversion-cleanup

Update supported Python versions
Motivated by this comment
<https://github.com/astropy/astropy/pull/2835#discussion_r15990257>
this adds the make_func_with_sig function to astropy.utils.misc.
Taking advantage of this, a new astropy.utils.compat.misc.wraps
function is provided as a replacement for functools.wraps, which
provides the same functionality but while also preserving the original
wrapped function's signature (so that it displays properly in help())
Turns out there are fewer usages of functools.wraps in Astropy than I thought. And most of them are in utilties/backwards compatibility features that aren't terribly important.  But I found this one case where the new wraps implementation is useful. And there could be others in the future.