Add method to get panel background color.
Refactor element mouse interaction.

There is an ambiguously-named method in the Element class that spurred
on this refactoring: onClick.

Surely this method began long, long ago with good intentions...

But now that Nifty has separated the idea of a click from a release, now
that there exists multiclicks, primary clicks, secondary clicks,
tertiary clicks, and combinations of clicking and releasing, this method
is embarrassingly outdated.

What it actually does is simulate a click-release of the primary mouse
button. "Simulate" means that normally all mouse actions are handled via
events, but in this case, the event system is bypassed and the mouse
action is handled AS IF it received an event.

This simulation is useful when we want to cause mouse actions to occur
that are not originated by the user. The only actual INTERNAL use case
for this currently is handling NiftyStandardInputEvent.Activate events.

Not only is the Element.onClick method name ambiguous, but the method it
delegates to is also ambiguous; that is, ElementInteraction.activate,
and the method that that method delegates to is also ambiguous:
ElementInteractionClickHandler.activate, and finally this last method
also delegates to another ambiguously named method,
MouseClickMethods.activate.

Why are they ambiguous? Because these "activate" methods are really
simulating a primary mouse button click-release. This "activate" concept
is a bad abstraction because in all these classes it is surrounded by
other methods that very specifically refer to mouse related parts and
actions (wheels, buttons, clicks, etc).

It's very important to have a consistent level of abstraction here. So
the solution is to rename all these "activate" methods to what they are
so that they harmonize with the other methods there, which means using
the phrase "clickAndReleasePrimaryMouseButton" or similar wording as
appropriate.

This renaming revealed that there were some methods missing for
supporting simulating secondary and tertiary mouse button
click-releases, so add those methods as well (most of the framework was
already in place for secondary & tertiary mouse actions).

Now we have elegantly solved the ambiguity of Element.onClick while
simultaneously adding some interesting features:

Element.onClickAndReleasePrimaryMouseButton
Element.onClickAndReleaseSecondaryMouseButton
Element.onClickAndReleaseTertiaryMouseButton

Now we can directly cause a click-release for either of the three mouse
buttons supported by Nifty, without having to dig through the code to
interpret the meaning of bad abstractions (Element class already
contains much explicit mouse-related functionality, so the above three
methods are not out of place).

Because the Element.onClick method is public, deprecate it rather than
deleting it (in line with other past refactorings of public Element class
methods). Refer users via the onClick javadoc to
onClickAndReleasePrimaryMouseButton.

Make Element.onClick delegate to
Element.onClickAndReleasePrimaryMouseButton.

Add extensive javadoc to Element.onClickAndReleasePrimaryMouseButton,
Element.onClickAndReleaseSecondaryMouseButton, &
Element.onClickAndReleaseTertiaryMouseButton to explain what they do and
in what situations they won't work. (This information was missing on the
Element.onClick method, making it even worse).

Change all internal callers of Element.onClick to use
Element.onClickAndReleasePrimaryMouseButton. Now, Element.onClick has no
uses internally and is ready to be deleted after the next release of the
library.

Element.onClickAndReleasePrimaryMouseButton is used internally to handle
NiftyStandardInputEvent.Activate events. The name of the new method is
self-documenting and should eliminate confusion for users implementing
custom controls and/or custom input mapping. They also now have the
option of mapping to secondary and/or tertiary mouse button
click-releases.

When Element.clickAndReleasePrimaryMouseButton is called, now not only
will a NiftyMousePrimaryClickedEvent be generated as before, but ALSO a
NiftyMousePrimaryReleaseEvent. The same applies for secondary & tertiary
mouse button click-releases. This was actually a preexisting bug that
has been fixed.

Other changes:

Remove all other methods from the Element class that were deprecated in
the previous version of Nifty. It should be safe to remove them now that
they are deprecated in the current release version of Nifty. None of
these methods were in use internally.

The multiclick mouse code was poorly written, not conforming to the
library's code style, contained spelling errors and poorly written
comments. This has been improved although it is still far from complete.
The logic of the multiclick code has not been changed.

All unit tests are passing, and integration testing was successful.
Rename jogl2 to jogl.

Rename nifty-renderer-jogl2 to nifty-renderer-jogl. Rename the actual
module directory and its reference in the main parent pom.

Why have version numbers in the module name? It makes no sense. Not only
would it be tedious to maintain as the version changed, but it's
inconsistent with all the other rendering modules. The whole point of
each module having it's own pom file is to specify the current version
in there.
Merge pull request #273 from 3xp0n3nt/get-panel-background-color

Add method to get panel background color.
Merge pull request #275 from 3xp0n3nt/refactor-mouse-element-interaction

Refactor element mouse interaction.
Merge pull request #278 from 3xp0n3nt/rename-jogl2-to-jogl

Rename jogl2 to jogl.
Merge pull request #279 from 3xp0n3nt/refactor-nifty-examples

Refactor Nifty Examples.
[Button] MoveCursorDown and MoveCursorUp don't check parent anymore

NextInputElement and PrevInputElement didn't check the parent of the
elements they change focus to/from. There is no known reason why it
should not be the same for MoveCursorDown and MoveCursorUp.
Added methods to listbox to retrive Scrollbars and buttonStepSize / pageStepSize.
Merge pull request #280 from relu91/1.4

Added methods to listbox to retrive Scrollbars.
Fix code style
Update Listbox
Merge pull request #281 from relu91/1.4

Fix code style for my previous pull request
Remove Java2D from Nifty Gui.

The Java2D renderer is some of the most outdated, nasty code in the
whole library. I don't think anyone uses it any more.
Add music looping to GdxMusicHandle.
Fix Hint Display Bug #246.

The Initial Problem:

The hint panel is a child element of the hint layer. Both the hint layer
and hint panel are initially invisible. The hint layer is shown when the
hint effect is executed. However, showing a parent element (the hint
layer) doesn't automatically show it's child element (the hint panel).

The hint panel is not shown, and the hint layer itself is actually
invisible (nothing to render). Unfortunately, it is not as simple as
calling Element.show() on the hint panel (as is done on the hint layer),
due to a pernicious bug in the Element class visibility code.

The Deeper Problem:

In the Element class, when calling Element.show() on an element with
children, the EffectEventId.onShow effect is propagated to all of the
Element's children. However, the method Element.internalShow() is only
called on the parent Element and not on the children, which allows for
greater flexibility such as showing a popup Element without
automatically showing all of it's children (if some children are already
hidden).

Once EffectEventId.onShow is propagated to a child element, that effect
remains active at least until the next frame. When calling
Element.show() on an Element that has EffectEventId.onShow as an active
effect, it's visibility will not be affected. So you cannot show() any
Element that has EffectEventId.onShow effect active.

To summarize the deeper problem, showing a parent Element prevents
immediately showing any of its children. Therefore, showing the hint
layer prevents showing the hint panel directly afterward.

Solutions that don't work:

1) Don't show the hint layer at all; just show the hint panel. Nope.
Unfortunately, you cannot show a child Element while it's parent is
hidden. That wouldn't make much sense anyway.

2) Okay, so show the hint layer, but show it with an EndNotify, and show
the hint panel inside the EndNotify.perform method. Nope. Unfortunately,
the EndNotify.perform method will never actually be called. It's
anyone's guess why. Probably another unrelated bug.

3) Just set the hint panel as initially visible! Since the hint layer
(parent Element) is invisible anyway, you wont' be able to see it until
you actually show() the hint layer. Nope. Unfortunately, the hint panel
is still invisible in this case, even after showing the hint layer.
Probably some strange "gotchya" in the EffectManager class, which deals
with such things.

Solution that does work:

1) Show the hint layer. Then force the EffectManager to stop the
EffectEventId.onShow effect on the hint panel (since it cannot be shown
while this effect is active, which was made active by it's parent).
Finally, show() the hint panel.

Fixes #246.

We really need to deal with this issue at a deeper level as the fix is
really just a kludge to get hints working again.