Use entry points to allow packages to register plugins/extensions in various parts of Astropy

There are currently several places where we allow or should allow packages to register extensions to Astropy. For example:

- The unified I/O interface
- Custom WCS to frame/frame to WCS mappings (https://github.com/astropy/astropy/blob/master/astropy/wcs/utils.py#L141)
- Custom serializations (https://github.com/astropy/astropy/pull/6619)
- Coordinate frames and transformations

The current workflow is for a package to append something to a list or call a register function. However, this is not ideal because it means the user has to know to explicitly import the package first. For example, let's say sunpy defined a ``.solar`` file format (I'm making this up, but hey).

If I just did:

```python
from astropy.table import Table
t = Table(...)
t.write('myfile.solar')
```

this wouldn't work. I'd need to do:

```python
from astropy.table import Table
import sunpy.io # making this up
t = Table(...)
t.write('myfile.solar')
```

The standard way around this kind of issue is to consider using entry points to set up a plugin system. With entry points, sunpy could then say it has plugins for file formats and provide the entry point to set up those file formats. This then allows astropy to discover plugins without the user having to import other packages explicitly (installing is enough).

To avoid a proliferation of ways of doing this, we should probably decide if we want to do this and then come up with standard entry point categories, e.g. ``[astropy.table.serialization]``, ``[astropy.table.formats]``, ``[astropy.coordinates.frames]`` and so on.

Note that if we had one entry point per Table format, we could also use entry points in the core package itself to register reader/writers instead of doing this ugly hack: https://github.com/astropy/astropy/blob/58fdc0115d0204c5bb64a36b5a24939190e4c396/astropy/table/__init__.py#L54

As a bonus, for Table formats, this could mean loading entry points only when the format is requested, which could improve import-time performance.

I'm opening this here to get some initial feedback - not sure if this should become an APE, or if this + astropy-dev discussion would be enough. Maybe we can see how controversial this idea is 😆

Start by reading the existing registration hack in astropy/table/__init__.py and the WCS mapping code in astropy/wcs/utils.py, then review the custom serialization discussion in pull request 6619. Compare the listed extension points and determine whether a common entry-point design is appropriate. Done means an agreed scope and standard entry-point categories, potentially captured in an APE or astropy-dev decision.

Written by the indexing model from the issue text.