Allow for custom datatype names in votable

This should allow end users to workaround VOTable files that contain
invalid datatypes.

Also adds two datatypes seen in Vizier tables: "unsignedInt" and "unsignedShort".
Update docs about datatype mappings.
Add changes entry.
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__
Updated bundled six module to latest version (1.7.3)
Performance and stability improvements to wcs.all_world2pix - 2nd iteration

This PR is a second iteration of PR #2373 with the main difference that
now the changes are on a branch (instead of master), hopefully does not
have (yet) merge conflicts, and addresses the issue of failing doctests
from PR #2373 by using data file name relative to the package as done
in PR #2807 and with updated output of the examples.

This (and #2373) provides significant improvements to the performance
(typically 1000-2000 times faster) and stability of `wcs.all_world2pix`
function. The used algorithm is a completely vectorized implementation
of the method of consecutive approximations (fixed point iterations).
While this method is a low-order method, it is more than adequate for
geometric distortions that are typical in astrophysical images (smooth,
slowly varying polynomials).

Compared to the original implementation of `all_world2pix`, this
implementation does not require users to have SciPy installed in order
to run.

While there is a check to see if WCS contains higher-order distortions
(and return the exact solution if it does not), the method itself does
not *require* this check and will converge to the exact solution after
one iteration if WCS does not contain higher order distortions. This
check is mostly for performance purposes to avoid unnecessary iterative
solution for images that do not contain distortions (and pix->sky
requires only WCS-based, i.e., CD-only transformations).

The proposed replacement for the current implementation of
`all_world2pix` avoids unnecessary use of `wcs_world2pix` and
`all_pix2world` such as `wcs_world2pix(all_pix2world(pix))` by
replacing this with `pix2foc`. This avoids unnecessary CD-matrix based
transformation CD(CD^{-1})=I which in itself results in about 50%
performance improvement over `wcs_world2pix(all_pix2world(pix))` and
likely 25% over `all_pix2world` alone.

The function has additional code to check for *divergence* condition
(as opposite to *slow convergence*) when consecutive approximations
*diverge*. This can happen when the pixel coordinates are *far* away
from the reference pixel (distortions are "severely" extrapolated), or
for poorly-defined geometric distortions (at least for this numerical
method).

A new and improved `NoConvergence` exception has attributes that allows
users to retrieve best solution reached by the function, and indices of
*slowly converging* solutions (points) that *did not converge* in the
specified maximum number of iterations as well as indices of
*diverging* solutions (likely an indication of poorly described
distortions or very large distortions).

Finally, the new test function `test_all_world2pix_direct` (proposed as
a replacement to the old test) provides a much more improved
(versatile) and *thorough* test of the `all_world2pix` function.

These improvements address the issues raised in #1977,
https://github.com/scipy/scipy/issues/3227 that plagued
`all_world2pix`, and #2294 (in addition to performance improvements).
Fix failing doctests

Trying to fix failing doctests dues to "unexpected exception".
Change phrasing to clarify that it applies to Quantity not Unit

Closes #2375
Added note to changelog
Made 1.7.3 the minimum six version
Initial refactoring so that every, or almost every model class shares a
generic __call__, with all the machinery for evaluating a given model in
a .evaluate() method that every model is required to have--preferably a
staticmethod or a classmethod so that it can implemented easily
independtly of the model class it belongs to.

The new system is not yet implemented for composite models or for
polynomial models, which will require some further refactoring.
Completed initial conversion of all models to use the new interface of implementing all its core calculation in an evaluate method.  This includes prepare_input and prepare_output methods that can be overridden by subclasses and used also by fitters.  The exact semantics of prepare_input and prepare_output I am not quite happy with yet--currently they do what is necessary to preserve the existing input handling, which I intend to rework.  Finally, Model.param_sets is no longer an ndarray, but just a normal list (albeit of ndarrays).  This was the only way I could get it to work consistently with multi-dimensional parameter values.  I plan to replace Model.param_sets with something else later.
Really, Model.evaluate should be an abstractmethod
Fix bad reference in the docstring; hopefully this will fix the doc build
Fixed up the new model examples to reflect the new implementation (no mention of process_input/output but I think that's a pretty advanced thing most models won't need to touch).  Fixed, I think, the documentation references that were failing
Remove dangling (and misspelled) reference to format_input
Remove stray __call__ implementation; this is no longer needed here
Fixed indentation in code examples