Phase 1 of improvements to I/O infrastructure

### Background

This PR implements delayed loading of read/write/identifier functions by allowing strings to be registered instead of functions, and when the functions are needed they are loaded. This should speed up the import of astropy.table by not importing all the rest of astropy when Table is needed.

(I had already started working on improving the I/O infrastructure in https://github.com/astropy/astropy/pull/2063 but decided to tackle it in smaller pieces)

### Issues

One of the issues I came across is that ``astropy.io.ascii`` auto-registers many ASCII formats via a meta-class. This is a problem because it means that in order to register the readers/writers, io.ascii needs to be imported which we want to avoid. But just to see if it would work, in the first commit (dcaf1a6ac35d7618bc59f11ef9e22b7d671093be) I implemented lazy loading for all readers/writers except io.ascii, but this doesn't work because we get circular imports when doing:

```
python -c 'import astropy.io.ascii'
```

because then it calls the meta-class in io.ascii, registers readers/writers, but during the registration of the registration, ``_update__doc__`` gets called, and then ``_register_builtins`` gets called for the first time and tries to import ``io.ascii``, raising an error because ``io.ascii`` isn't loaded yet.

The second commit (a9b1d9e93a2d53d6b16c0fff21a28b89eba4b2d3) and the PR in its current state therefore hard-codes the ASCII readers/writers by hand in ``registry.py`` (but using some ``partial`` magic to avoid having to make any changes in ``io.ascii`` related to how the readers/writers are handled).

### Benefits

One benefit of the new system is that all the readers/writers are defined in one place and it provides a unique place for developers to go when adding/removing built-in formats.

Because of the new deferred importing infrastructure, importing ``astropy.table`` is now faster. Before:

```
$ time python -c 'from astropy.table import Table'

real	0m0.921s
user	0m0.843s
sys	0m0.056s
```

After:

```
$ time python -c 'from astropy.table import Table'

real	0m0.511s
user	0m0.468s
sys	0m0.039s
```

and part of this comes from importing astropy itself:

```
$ time python -c 'import astropy'

real	0m0.237s
user	0m0.202s
sys	0m0.033s
```

so importing astropy.table is 2-3 times faster.

### Next steps for this PR

If we go ahead with this PR I can add tests that try and ensure that the list of readers/writers in ``registry.py`` is up to date with the readers/writers in ``io.ascii``.

### Phase 2 (separate PR)

Note that in Phase 2, I plan to work on the idea that was suggesting before of making use of I/O classes instead of functions, but wanted to do things one step at a time. Note also that the above issue with ``io.ascii`` demonstrates that self-registering classes may not actually be a good idea if we also want delayed registering/importing of modules - that is, in the present PR, the HDF5 readers/writers are actually only accessed if absolutely needed. However, if they are in a self-registering class, that class can't self-register unless the code is executed. If we use delayed imports of that class as in this PR, there is nothing gained from making the class self-registering. We can still use non-self-registering classes to encapsulate the reading/writing/identifying functionality as well as any documentation for those.

@taldcroft - it would be great if you could share your thoughts on this PR.

cc @embray @eteq @mdboom
I think I get that.  One thing I also had in mind that would make things simpler if there was just one data structure that could be read in which describes all the supported formats and the associated configurations for reading/writing that format.  Putting it all in a big dict, for example, would be easier to digest than a bunch of `register_` calls, but that's subjective on my part.