Minor LibGDX examples cleanup.

- Upgrade Nifty version in LibGDX examples. Pom value in nifty-examples-libgdx
  pom incorrectly specifies 1.4.0. Change to 1.4.1-SNAPSHOT.

- Fix LibGDX android examples. Remove nonexistent configuration value
  'useGL20'.
Merge pull request #250 from relu91/1.4

Multiclick support for builders
Merge pull request #255 from 3xp0n3nt/libgdx-cleanup

Minor LibGDX examples cleanup.
Update <nifty.version> to 1.4.1-SNAPSHOT to fix compiler errors
Fix NiftyStandardInputEvent.Activate bug.

NiftyStandardInputEvent.Activate only simulates a mouse click, but not a
mouse release. This causes a bug where only listening for
ButtonReleasedEvent's but not ButtonClickedEvent's for a specific button
will cause input mappings to NiftyStandardInputEvent.Activate to not
work with that button. This results in undesirable & unexpected behavior
such as pressing the enter key on a currently focused button does not do
anything.

The solution is to make NiftyStandardInputEvent.Activate simulate a
mouse click and a mouse release, so that when
NiftyStandardInputEvent.Activate is triggered, a ButtonReleasedEvent is
fired in addition to the ButtonClickedEvent.
Allow SizeValue floating point values.

Modify the internal storage of SizeValue to use a float rather than an
int to allow for floating point values in SizeValue strings.

Add SizeValue tests to verify that floating point strings are accepted
as valid values and are parsed correctly.

SizeValue.getValueAsInt now rounds the floating point pixel values to
the nearest integer using Math.round, which is the safest way to do it.
It is also consistent with the already existing behavior for floating
point percentage values, which already uses Math.round in the
getValueAsInt method (it was added to fix a subtle truncation bug
causing off-by-one pixel errors).

Fix failing tests in
nifty-core/src/main/test/java/de/lessvoid/nifty/layout package by
verifying resulting SizeValue strings as a decimal value instead of an
integer value. For example, new SizeValue("100px").toString() will now
equal "100.0px" instead of "100px".

The SizeValue.toString method is the only place where the extra ".0" in
(for example) "100.0px" as a string will come into play because even
though most of the time it will be a whole number, now there is the
chance that it could be something like "100.5px". It seems to be the
most reasonable behavior to always have the decimal and trailing zero
for "whole number" SizeValue.toString outputs, rather than only having
the decimal when it is not ".0". This could be considered a significant
change, but it doesn't break anything because only the output format is
changing - SizeValue still accepts "100px" (with no decimal) as a valid
value, it just converts it to "100.0px".

The SizeValue equals & hashcode methods were deleted and replaced by
auto-generated versions from IntelliJ, which are safe because they both
rely on the Float.floatToIntBits under the hood for the internally
stored float value. Tests have been added to SizeValueTest to verify
that equals is working correctly. For example, new SizeValue ("10.0px")
should be equal to new SizeValue ("10px"), but new SizeValue
("10.0001px") should not be equal to new SizeValue ("10px") nor new
SizeValue ("10.0002px").

Fixes #244.
Merge pull request #256 from 3xp0n3nt/activate-click-release-bug

Fix NiftyStandardInputEvent.Activate bug.
Merge pull request #257 from 3xp0n3nt/sizevalue-float-percentage

Allow SizeValue floating point values.
Implement Slick2D batched rendering.

Slick is old and dying. My research shows that there is only one person
that has even attempted to maintain it in the last year or so (kudos to
nguillamin at https://bitbucket.org/nguillaumin/slick and
https://github.com/nguillaumin/ who maintains his own fork of the main
slick repo at bitbucket).

Similar to Nifty, Slick has it's own rendering systems and OpenGL
abstraction. So they are not compatible with each other. Both Nifty and
Slick cannot control UI rendering simultaneously.

So the current workaround to make Slick work with Nifty has been to
provide SlickRenderDevice, a direct implementation of RenderDevice, that
ultimately delegates all control to the Slick internal rendering system.
So Slick is basically given full control of UI rendering.

The problem with this approach is that it effectively bypasses the
entire new batch rendering system built in to Nifty (where Nifty has
full control of UI rendering - the exact opposite of the above
situation).

For the above reasons, every direct implementation of RenderDevice in
the entire Nifty Gui library is marked as deprecated (and soon to be
removed). These implementations are also horribly outdated (using
ancient immediate mode OpenGL) and are preventing Nifty from moving
forward more quickly to stay relevant as a modern OpenGL-based UI
rendering system.

The new Nifty batch rendering system has consolidated rendering control,
only requiring other libraries that wish to "plug in" to Nifty (LibGDX,
LWJGL, JOGL, etc) to implement a simple OpenGL interface, and a couple
other simple interfaces for the creation of mouse cursors, buffers, and
images. There is also an OpenGL Core-Profile-based batched rendering
system in Nifty, but as Slick cannot support this, it will not be
mentioned here. You only need to know that a plugin library can either
provide support for the compatibility batched rendering system (the one
discussed here), or the core-profile batched rendering system, or both.

In order to integrate Slick with the compatibility (non-core profile)
batched rendering system in Nifty, it means that Slick must be able to
surrender UI rendering control completely. The way that this is
accomplished is by bypassing the Slick renderers completely and
accessing OpenGL straight from the underlying LWJGL, which Slick is a
wrapper of.

Theoretically, the Slick-based rendering system (the one being bypassed)
could still be used for non-UI game rendering, while UI rendering would
be managed by Nifty. What this means is that you could continue to use
Slick in the way that you are used to, as the changes will only affect
Nifty under the hood, so to speak. I say "theoretically" because this
has not been tested. The nifty-examples-slick package provided with
Nifty only demonstrates pure UI rendering - meaning that there is no
game being rendered by Slick underneath the UI.

So, nifty-renderer-slick can now work with the batched rendering system
(compatibility / non-core profile only). If you use the provided Slick
convenience classes, such as NiftyGame & NiftyGameState, the new batched
renderer is used automatically. If for some reason you wish to
create/initialize/manage the Nifty instance yourself, you pass in:

  new BatchRenderDevice(SlickBatchRenderBackendFactory.create(), ...);

as the first parameter (RenderDevice) to the Nifty instance.

SlickRenderDevice has been marked as deprecated, and is no longer used
internally.

The new batch rendering classes are in a new 'batch' package inside
de.lessvoid.nifty.slick2d.render, to prevent confusion / mixing with the
old rendering system classes.

The examples in nifty-examples-slick have been modified to work
automatically with the new batched renderer, and integration testing
shows that they work just fine (Caveat: there is some small artifact in
the top left corner of every screen - which I believe may be some kind
of FPS counter - that does not display properly, hopefully someone can
fix this.)

That said, this feature should be viewed more as a band-aid to an
outdated and (mostly) dead library.
Merge pull request #260 from 3xp0n3nt/slick-batch-renderer

Implement Slick2D batched rendering.