Make Horizons queries robust to target name

[mkelley]

Target names could resolve to multiple objects and/or orbits. The Horizons code needs to be able to handle this possibility and make the user aware of the result. Here are some examples:

• Europa is the name of a satellite of Jupiter and asteroid 52. astroquery's id_type can be used to get one or the other.
• Encke is the name of a comet (2P/Encke) and an asteroid (9134 Encke). Again, use id_type here.
• 2P will also return many orbits for this comet. Use closest_apparition=True and id_type="designation" to pick the most current orbit.
• 73P will return many orbits for this comet, but also many fragments. To avoid fragment matching, add no_fragments=True

[szilac]

I will change the input information (targets.csv). So far the columns look like this: # target, start_time, end_time, step I will insert +1 column as "target_type" which can be asteroid or comet. By modifying the Horizons (and Miriade) interface one can set the appropriate options for the query.

[szilac]

I have changed the QueryInput data. It should now contain a keyword for the object type. Currently it still follows the Horizons keywords like smallbody, asteroid_name, comet_name, designation, but I will change that. If you want to retrieve comet ephemeris data, miriade_interface will call the find_sso method from astroquery.ESASky to retrieve the corresponding name. Unfortunately, for Miriade I couldn't find any switches like in Horizons (closest_apparition, no_fragments) so this needs to be tested to see how it works in such boundary cases.