Refactor use of __init__ in io.ascii Readers

In the Readers, there are 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 hierarchy, 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).

Note that I had to move a lot of code around to make sure stuff is not used before it is defined (since now objects are needed at compile time that before were only needed when called).

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
`BaseClass.__init__(self)`.

This is a partial answer to #2810

@cc taldcroft @amras1
I've been pondering whether this change from using the class attribute directly to the instance attribute can have any subtle effect.  Do you think the original (here and in BaseData) was actually wrong or were you changing for style reasons (because it looks more natural)?