validate NCName parts of xsd:QName in lexQName

[aizu-m]

Found while checking how the rich parser turns element text into a QName.

XMLStreamReaderExtImpl.getQNameValue() on <a xmlns:p='urn:x'>p:b:c</a>
returned {urn:x}b:c, a local part with a colon still in it

lexQName splits the value at the first colon and keeps everything after it as the local part, but it never checks that the prefix and local part are NCNames. So p:b:c, b c and p: all came back as QNames rather than being rejected as outside the xsd:QName lexical space. The rich parser getQNameValue / getAttributeQNameValue getters are the only callers of this overload, so the bad value flows straight in from untrusted XML.

JavaQNameHolder.parse on the validate path already guards both parts with isValidNCName. I added the same two checks to lexQName so it throws InvalidLexicalValueException, which getQNameValue already catches. Leading-colon handling and prefix resolution are unchanged.