JSON Parser for Datalinks

[d-giles]

As data becomes available from different cloud providers, some services are including cloud access information in the associated Datalink in JSON format.

This PR adds functionality to the DatalinkRecordMixin and the DatalinkResultsMixin to handle basic parsing of JSON entries in a uniform way. The methods ask for a column name and a key to identify specific entries in the JSON to parse and return, and allows matching other named parameters. The parsed JSON entries are returned in an astropy.Table with added columns to indicate the row of the original Results object to which the row belongs, and the row of the DatalinkResults where applicable.

While JSON entries are non-standard at present, they are not disallowed in DatalinkResults and are currently being included without official standard or guidance. This PR does not impose a standard, but provides a set of convenience functions which facilitate the use of existing data.

[codecov]

Codecov Report

❌ Patch coverage is 90.90909% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.12%. Comparing base (76a9ce9) to head (2afc229).
⚠️ Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
pyvo/dal/adhoc.py	90.90%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #709      +/-   ##
==========================================
+ Coverage   84.03%   84.12%   +0.09%     
==========================================
  Files          79       79              
  Lines        8529     8610      +81     
==========================================
+ Hits         7167     7243      +76     
- Misses       1362     1367       +5     

☔ 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.

[msdemlei]

Thanks for taking pyVO on this presumably inevitable path. I think we can in principle merge this even before there is any proper agreement on how this should eventually look like.

However, I'd like it a lot better if there were not, for now, a default cloud provider; at least during the prototype phase, people should need to explicitly pass these in.

Also, I'd auto-detect columns based on an invented UCD (meta.ref.cloudstorage, say). If this turns out to work, we can always get it sanctioned. The alternative of using a utype ("adhoc:cloudstorage") could later interfer with obscore (though it really shouldn't). I'd not insist on that, though. If you say "no, I want bespoke column names", you'd have my blessing, too.

But most importantly: please make it crystal clear in the documentation that this is a draft API that is probably subject to change.