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
Before this change we sometimes changed the properties of a spitter object of the inctance in `__init__`, in at least one case even the class. 
If `class B(A)` and class A changes the splitter class in its `__init__`, then the instance of B will have `self.splitter  = classAsplitter` at this point. Thus, the old form was required to allow B to define its own splitter.
Now, such definitions are no longer made in `__init__` so this is no longer required. If you go through the code, you will see that `self.__class__.spliter_class()` is an exception (presumably put there because of the problem I just described). Everything else is instanciated using the instance object e.g. `self.header_class` not `self.__class__.header_class()`, `self.outputter()` not, `self.__class__.outputer()` etc.

Initializing an object using the instance variables is the normal case in python and if a *user* attaches a new splitter class / outputterclass/ ... to an instance then he/she  probably expects that class to be used, not the hardcoded version in the class object.

So, you could say that me changing this now is just "style", but it removes an exception in the implementation that was required before due to the way `__init__` was implemented and that is no longer needed.