#3520041: Window DragNDrop multiplies events

In general when a popup is being shown (nifty.showPopup()) all of the
controls it contains are initialized (and in case of the button
control are registered with the EventBus). When the popup is closed
all controls are automatically removed from the EventBus. So popups work
in the general case correctly.

But when a drag operation starts the content of the draggable was being
moved to a newly created popup (with a call to markForMove()) and after
that the popup was displayed (using nifty.showPopup()). So in that case
all the controls - the content of the draggable that have been
initialized already - would be registered AGAIN when the content moves
to the popup! And because when the drag operation ends the content is
moved back and then the popup is closed - and since the content is
already gone the popup when being closed doesnt contained any elements
anymore. So the removal from the EventBus in the button case didn't work
at all too :)

So after the long explanation the fix actual was easy: when the drag
operation starts we will now show the popup first and THEN move the
content to the popup! This way no duplicate registering with the
EventBus is happening and everything should work as expected again!

PS: Another bug has been fixed as well: when the drag operation ends
Nifty looks for droppables at the current position. While doing this
Nifty didn't check if the droppables are visible! So it was possible
that you have some hidden droppable and when you incidentally drop
something at that position it would be possible to drop a draggable to a
hidden droppable - with the effect of your droppably disappearing! Crap!
But thats fixed now! :)
screen.debugOutputFocusElements() added to output focus information

This is helpful to get a debug string of all elements that are currently
focusable.
improved exception Logging and Element move focushandler fix

- improved logging of exceptions especially of exception stacktrace
- when elements are being moved from one parent to another the elements
are removed from the focushandler of the old parent and are now again
added to the focushandler of the new parent
addElementAfter() added to the FocusHandler
experimental change for mouse event handling

The old way of handling mouse events had some problems especially with
EventBus events.

Here is a (long) explanation:

When you use the <interact /> callback methods like <interact
onClick="..." /> everything is fine. Mouse events will travel down all
elements that are visibleToMouse="true" until some element has been
found with an <interact /> kind event handler set. When the event
handler is found this mouse event is consumed and is not send to any
other elements "below" the element. All is fine.

However there is a problem with this approach especially with EventBus
events. EventBus events are published and because of their very nature
are not able to provide any information if the event has been consumed
by anybody or not at all. This is a problem when you imagine overlayed
elements, like a button on a panel and you have a <interact
onClick="..." /> on the panel but you're using the Eventbus
ButtonClickedEvent for the button.

So when Nifty processes the mouse click event it will be first sent
to the Button (because it is "above" the panel) which publishes it to
the EventBus event AND then the event will be forwarded to the panel
below as well. The panel has the <interact onClick="..." /> event
handler set which is executed and event handling stops at the panel
level.

The problem is that we've now executed two event handlers (for the
button and the panel) even though we'd probably expect only the top most
element to be called.

This behaviour has now been changed like so:

To keep things simple Nifty will now stop processing directly when it
encounters the first visibleToMouse="true" element. This means events
will now don't travel any further. When you have two elements above each
other that both have visibleToMouse="true" then only the topmost element
will now get the event.

Please Note:

To make this work some of the default controls need to be changed
slightly. It might be necessary to change your code slightly as well!
Especially you must now be careful where you add visibleToMouse="true"
because this can now really block events from travelling down the
element tree.

We're not sure if this will solve all problems but it it at least a
straightforward simple solution. There is no second guessing anymore
where events hit elements and so on. We're not too happy with this but
we'll need to check this in practice (therefore the commit).