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
Look at the new line 1125 in this file (I don't know how to reference that in Markdown). There is a keyword "strip_whitsspace" that overrides the `process_line` defined in a class. 
Before this PR `Class.process_val.__get__(obj, Class)` would give the process_val version from Basic, since most changes where done in the `__init__` (or at least, for the cases tested it gave that). Now, we use proper inheritance, so `process_val = Class.process_val.__get__(obj, Class)` would not change anything.
I am not quite sure what this option is good for (for most reader, `process_val` stript the white space anyway and for those where it does not, there is a good reason why), but to keep backwards compatibility, I had to hardcode a function for `process_val` in line 1125. According to the documentation, this option would "strip whitespace", not "strip lefthanded whitespace". So, I chose `x.strip()`. Then, I compared to the original definition in this line here and found that it stripped only lefthanded space, so I changed that, too, to bring it in line with the documentation.

Is suspect that `strip()` and `lstrip` here have the same effect, at least if splitting on whitespace, anyway...

All tests pass, so if this screws something up, it most be an uncommon case (if you find one thne we should add that as a test case).