…uthor and Freetext constraints

This introduces expected_columns in existing regtap.RegistryResource,
which I now intend to re-use (and evolve) for the data discovery, too.
It will now declare what columns are required from the queries itself
(where I suspect we'll have to be a bit niftier if we want more
advanced categories of data we get in the initial discovery query).

Also, I've found that we can keep the existing registry.search interface
(and adding another interface isn't worth the extra effort).  Hence,
I've renamed the previous datasearch to rtcons ("RegTAP constraints").

This breaks regtap.search, though, because I'm already preparing the move
to using rtcons in there (maintaining includeaux).

Also, adding the forgotten _keyword attributes for Waveband and Servicetype
so they'll later be found when moving regtap.search.

This required changing some of the constraints in order to keep the
existing call patterns stable.

…arly

multi-interface results.

We're now also retrieving the interface type because we may want
to do something with web interfaces at some point.

Also, waveband validation is now case-insenstitive.

…ion.

Also, refactoring service type selection to use a global SERVICE_TYPE_MAP
for the various aliases for the standards.

Also, adding an Ivoid constraint for just retrieving a specific resource.

Interfaces now know if they're VOSI and are filtered by service,
new way of expanding and shortinging standard ids.

But we're stuck a bit because of a conspiracy between RegTAP's
NULL mapping rules, ivo_string_agg's NULL skipping, and the lack of COALESCE
in ADQL.

This is nice and makes our "get all interfaces"-queries work.  It's
only downside: This only exists in bleeding-edge DaCHSes, as far as
ADQL is concerned.

The effect of this commit is that you can say svc.get_service("tap") and receive
a TAP service if there's a tap or tap#aux capability.  You can now also say
svc.get_service("web") to get a browser interface.

…ld do tech support.

Also, changing the default endpoint to reg.g-vo.org, which is dc.g-vo with
failovers in case anything is funny in Heidelberg.

when services declare multiple data models with matching prefixes.

Actually, you can even use ivoids if things really need to be repeatable.

…constraints.

That is:

* Changelog mentions PR rather than bugs
* __all__ declaration for the rtcons module.

The previous code assumed that typically, records only have one capability,
which is no longer true as soon as people do not constrain by servicetype
(actually, it hasn't been true before either).

So, describe() now gives the various access methods and no longer tries
to indicate a specific capability.  I have re-shuffled the order of
the outputs a bit in consequence.

And I wonder if this should show contact information by default.  The
main counterargument at this point: That requires a network request.

This corresponds to the legacy behaviour.

This addresses review comment
astropy#289 (review)

This points back to the parent instance.

This is an attempt to address
astropy#289 (comment)

Also, adding a __repr__ method to regtap.Interface that returns a
constructor call literal.

This is in response to
astropy#289 (review)

This is because overwriting DALResults.to_table proved a bad idea
(see astropy#289 (comment))

The messenger_vocabulary fixture should have made them non-remote, but
I've never actually tested that.  It now turns out that astropy.data doesn't
use requests and hence my nice requests mocker just didn't work.

I've now replaced it by code seeding astropy.data's cache.  This is a
pattern we ought to use whenever code uses IVOA vocabularies.  I wonder
where we should document this?

(sorry; also, I'm busy elsewhere, so I'll address the remaining issues on
Monday)