dont pollute the libxmlsec/libxml2 global state with error handlers #7
Description
whenever a golang thread invokes startProcessingXML() we take over the libxmlsec error handler (which is process-global) and the libxml2 error handler (which is per-thread)
If other packages are using cgo and libxml2 or libxmlsec in the same process we'll possibly break 'em, which isn't nice.
Part of the right solution is to have a c function invoked from stopProcessingXML() which unregisters our libxml2 handler.
For libxmlsec, the problem is subtler because we don't know if another goroutine might be calling xmlSecErrorsSetCallback somewhere. Ugh.