Fix issue where a GenericMessage cannot be encoded to XML.

[kbalthaser]

Potential fix for issue where GenericMessage instances cannot be encoded to XML using the DefaultXmlParser. closes: #20

This may not be an ideal solution from a performance perspective, but it was a simple way to address the issue.

We are currently using a custom XmlParser which implements this same change. Having this within HAPI itself would certainly help streamline our code.

[ohr]

XML encoding of GenericMessages (i.e. messages with unknown structures) is not supported (see XMLParser#doEncode(Message)), even with your fix.
If it was allowed, I doubt that these messages could ever be parsed back into XML.

[kbalthaser]

Interesting. I can say from our experience, you will never actually see that Hl7Exception come out.

If you look at the sample test I included, and run that against unmodified code, you can see that in this usage, you do not get the "nice" message referenced in XMLParser#doEncode(Message), that method is not called by the DefaultXmlParser implementation. I personally would have saved a bunch of time had I actually encountered the proper message.

Ex:

ca.uhn.hl7v2.HL7Exception: Can't create XML document - org.w3c.dom.DOMException
        at ca.uhn.hl7v2.parser.DefaultXMLParser.encodeDocument(DefaultXMLParser.java:124)
	at ca.uhn.hl7v2.parser.XMLParserTest.test_encode_GenericMessage(XMLParserTest.java:458)
...
Caused by: org.w3c.dom.DOMException: INVALID_CHARACTER_ERR: An invalid or illegal XML character is specified. 
	at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.checkQName(CoreDocumentImpl.java:2603)
	at com.sun.org.apache.xerces.internal.dom.ElementNSImpl.setName(ElementNSImpl.java:121)
	at com.sun.org.apache.xerces.internal.dom.ElementNSImpl.<init>(ElementNSImpl.java:84)
	at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createElementNS(CoreDocumentImpl.java:2121)
	at com.sun.org.apache.xerces.internal.dom.CoreDOMImplementationImpl.createDocument(CoreDOMImplementationImpl.java:274)
	at ca.uhn.hl7v2.util.XMLUtils.emptyDocument(XMLUtils.java:128)
	at ca.uhn.hl7v2.parser.DefaultXMLParser.encodeDocument(DefaultXMLParser.java:117)
	... 24 more

In my use-case, we never actually have to go backwards from XML to a PipeMessage, so my thinking is obviously biased :)

If this is truly unsupported in default HAPI, would you like me to make a PR which throws the proper exception out of DefaultXmlParser#encodeDocument(Message) ?