Add get_zeropoint and more flexible metadata querying to SVO FPS

[keflavich]

There is metadata on SVO FPS that is inaccessible but should be.

#3528 showed the right mechanism to retrieve metadata, but it didn't allow querying on PhotCalID - while data_from_svo allowed specification of this parameter, the mechanism we are using to parse the votable drops the relevant data.

This PR adds a new get_zeropoint mechanism to very explicitly and cleanly retrieve zeropoints and also generalizes get_filter_metadata.

Note that I have made some serious mistakes in recent publications because I failed to realize the default zeropoint was vega, so it's high importance for me to expose the get_zeropoint method with an explicit mag_sys keyword to users.

[codecov]

Codecov Report

❌ Patch coverage is 90.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 73.26%. Comparing base (44c0c4c) to head (ac4b698).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
astroquery/svo_fps/core.py	90.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3545      +/-   ##
==========================================
+ Coverage   73.20%   73.26%   +0.05%     
==========================================
  Files         226      226              
  Lines       20966    20975       +9     
==========================================
+ Hits        15349    15368      +19     
+ Misses       5617     5607      -10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cgobat]

Nice. I like it.

[bsipocz]

The changes look good, and tests are happy.

However, I'm less happy about introducing back the **kwarg approach. Could we maybe expand it out and list all the options explicitly? If nothing else, it would make the docstring more useful.

[bsipocz]

can we be more specific about the acceptable kwargs? Or is the list very long?

(I try to get rid of these wildcarded kwargs as they swallow a lot of problems as users can pass on practically anything even if it has no effect; besides it means that our documentation is practically useless.)

[bsipocz]

I would still think we should spell these out; if for nothing else to show the users of what parameters are available.

[keflavich]

the kwargs are specifically query args that then go through validation

query.update(kwargs)
bad_params = [param for param in query if param not in QUERY_PARAMETERS]

we could refactor to put all these as explicit parameters:

# Valid query parameters taken from
# https://svo2.cab.inta-csic.es/theory/fps/index.php?mode=voservice
_params_with_range = {"WavelengthRef", "WavelengthMean", "WavelengthEff",
                      "WavelengthMin", "WavelengthMax", "WidthEff", "FWHM"}
QUERY_PARAMETERS = _params_with_range.copy()
for suffix in ("_min", "_max"):
    QUERY_PARAMETERS.update(param + suffix for param in _params_with_range)
QUERY_PARAMETERS.update(("Instrument", "Facility", "PhotSystem", "ID", "PhotCalID",
                         "FORMAT", "VERB"))

would you prefer that? It's 21 parameters, but maybe it's more helpful to users to have them all explicitly specified?