ttools: fix taplint to accept application/xml as well as text/xml

In the UWS stage in some cases taplint used to require a content-type
of text/xml from some resources.  This looks like the sort of thing
I'd have put in because it was written in some standard somewhere,
but I can't find any trace of it.  So relax it to permit application/xml
as well - either is a reasonable way to indicate XML content.
ttools: provide taplint with VOSITables schema

taplint was generating the following warning when validating the
/tables endpoint for some services:

   W-TMV-UNSC-1 Schema from unknown namespace during validation: http://www.ivoa.net/xml/VOSITables/v1.0

I'm not sure why I hadn't noticed this before, or why I hadn't included
the VOSITables schema in taplint's hardwired schema collection before.
Anyway, I have now, so this warning will go away.

NOTE, as pointed out to me by Gregory Mantelet, and earlier
(July 2014) noted by Markus Demleitner on the grid@ivoa.net list,
there appears to be an error in the copy of that schema currently
(29 Oct 2014) hosted at the canonical location
(http://www.ivoa.net/xml/VOSITables/v1.0) - it's got its namespaces
in a twist.  Maybe that's the reason I didn't include it before.

Therefore the VOSITables-v1.0.xsd schema included in this commit
has been copied'n'pasted from the VOSI 1.0 REC standard text
(Appendix A.3), with some whitespace formatting errors and
annoyances adjusted.
ttools: treat unicodeChar like char for taplint type matching

taplint checks column type declarations in various places, and
reports a W_CTYP or E_CTYP in case of a mismatch.  This is done
according to the table in TAP v1.0 sec 2.5.  That table mentions
datatype "char" but not "unicodeChar", which is a bit unfair,
since it gives data providers no way to declare that they will
be emitting unicodeChar in VOTable output.

So this fix (lobbied for, entirely reasonably, by Markus) allows
unicodeChar content wherever char content would otherwise be permitted.
This is contrary to the letter, but in line with the spirit, of
the TAP standard.
ttools: taplint allows anyURI in dataModel ivo-id

There is an Erratum (#1) currently going through the system to redefine
the ivo-id attribute of TAPRegExt's dataModel element from
vr:identifierURI to xs:anyURI (so it can have a fragment identifier).

This commit reflects that erratum in taplint.

First, we need to adjust the TAPRegExt xml schema document,
changing the declared type of dataModel/@ivo-id,
so that the capabilities validation stage does not emit an error.
I've used a new TAPRegExt xsd document here labelled -Erratum, rather
than doing violence to the existing one; this version is not official,
I've doctored the existing one.

Then I added additional logging in the Capabilities stage to warn
if the ivorn does not match the regex corresponding to the
vr:identifierURI type.