Performance improvements to Xul parser and Swing

Pentaho-Xul uses a awful way of doing translations by forcing a already parsed XML-Document back into an text-stream, then doing a lot of string-replacements, and then parsing that whole thing back in.

Something similar happens to normalize the ID attribute to upper-case. 

Not only is that a waste of memory, CPU cycles, it is also quite insecure. The string-conversion relies on the systems's default locale for some operations, happily ignoring that XML is not a text-format but a carefully crafted binary format that looks like text. Therefore a non-UTF windows system can break UTF-encoded Xul documents quite easily.

Parsing a XML document into a DOM to then write it out to an XML-text deserves no comment at all.

This patch fixes the parser to use DOM traversal to translate all attribute values and to normalize the ID attribute. Your Garbage Collector will be relieved. :)


This change kicks in to its fullest when you have a lot of overlays and includes for your dialogs.

----

Second patch: 

Swing-Xul was non-performant. A large chunk of time was consumed by the need to go through reflection for creating XulComponent implementations. I replaced that with a Delegate-Interface. Sure, the SwingXulLoader looks ugly now with all the inner classes, but it is lightning fast.


SwingTree was doing abnormal work due to a false reliance on "JTable#updateUI()" and a Cell-Editor implementation that drained the life out of my CPU.

UpdateUI is only needed when you change your Look-And-Feel implementation. It does not do any good otherwise. By kicking it out, you safe yourself a lot of waiting. The CellEditor used in SwingTree was a interesting mix of code. I simplified it to a delegate editor which forwards all calls to separate named implementations. These implementations can be reused now, greatly lowering the drag on the memory when working with larger tables.


-----

Running the SwingLoader to create a Barcamp demo screen 200 times (after 200 warmup-cycles) reduces the time for the task from 6600 msecs to now 2500msecs. 

If we were to replace SwingLabel's component (a JTextEditor) with a plain JLabel for simple one-line text, we would actually come down to 1900msecs. This would be a 300% improvement over the original code's performance.