ENH: Better align jplhorizons with the corresponding API

My experience with the current jplhorizons sub-module suggests to me that it requires more maintenance than what I think is ideal. In addition, since it was written astroquery, astropy, and Horizons have evolved substantially, including the publication of a versioned Horizons API. I am attempting to write a new jplhorizons module from scratch that is at its heart aligned with the Horizons API as closely as possible, but also taking advantage of key astropy/astroquery infrastructure. I also want a user to be able to primarily refer to the Horizons documentation to develop their query, then implement it with astroquery as seamlessly as possible.

For the moment, I'm calling this new implementation `Horizons2`.

Some design goals:

1. method names closely map to Horizons ephemeris (output) types, e.g., `Horizons2.query_observer` for EPHEM_TYPE=OBSERVER, see https://ssd-api.jpl.nasa.gov/doc/horizons.html#ephem_type
2. named method arguments and keyword arguments would be used to form the object query, i.e., the API's COMMAND parameter, see https://ssd-api.jpl.nasa.gov/doc/horizons.html#command
3. an additional keyword argument would be used to specify the center of the coordinate system (e.g., the observer for an ephemeris), and could handle astropy `EarthLocation` objects
4. the usual astroquery keyword arguments will be respected, e.g., `get_query_payload=` and `cache=`
5. all other parameters are unnamed keyword arguments passed on to Horizons as is
6. the returned data will be packaged into an astropy `Table` without any column renaming and including all relevant metadata in the `Table.meta` attribute
7. columns will be given units as appropriate
8. columns with dates will be converted to `Time` objects
9. when practical, sky coordinates will be copied to an additional column and packaged as astropy `SkyCoord` objects, with the appropriate reference frame defined
10. it should be aware of which Horizons API version it supports and will raise a warning or an error if the API response does not match an expected value

Ultimately, I'd like to more easily support all of Horizon's features, future-proof or at least simplify most minor version updates to the Horizons API, and keep the majority of the maintenance limited to astropy+astroquery version support.

This issue is intended to announce the development of `Horizons2` and to collect questions and feedback. I have a branch started at: https://github.com/mkelley/astroquery/tree/horizons2 Time frame for completion is probably six to twelve months.