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.
Catching a possible NPE on linux systems that are caused by a bug in the java runtime.

For further information: JDK-6322854
Merge pull request #265 from mkaring/1.4

Catching a possible NPE on linux systems
Add LibGDX input forwarding customization.

Make it possible to forward input events unhandled by Nifty to multiple
custom LibGDX InputProcessor's. Currently, the GdxInputSystem used by
Nifty consumes all input. On the other hand, if you try and capture
input via LibGDX directly, for example to get input directly for your
game that is being rendered underneath the Nifty UI, then Nifty will not
receive any input.

The problem with the current setup is that it's an either-or approach,
so either 1) Nifty (the UI) will consume all input, or 2) some custom
InputProcessor set by the LibGDX method Gdx.input.setInputProcessor
(myCustomGameInputProcessor) will consume all input (the game).

What is needed is for Nifty to share nicely with others. ;-) So modify
GdxInputSystem to use LibGDX's InputMultiplexer, which supports multiple
InputProcessors simultaneously. Modify the GdxInputSystem constructor to
allow the optional addition of multiple custom InputProcessors. Add
methods to GdxInputSystem to append, insert, remove, clear, and get
custom InputProcessors.

The new way GdxInputSystem will work by default is that Nifty will get
first dibs on any input. If Nifty does not process the input, then any
custom InputProcessor's that are set will receive the input, in the same
order they were added / inserted.

However, there is now the possibility of specifying that Nifty will
receive input AFTER all of your custom input processors. (This is not
the default behavior as most use cases will have Nifty as a UI
overlaying a game, so it makes sense to allow the UI a chance to handle
the input before the game.) Add an additional constructor to
GdxInputSystem that allows passing in the enum NiftyReceivesInput.FIRST
/ NiftyReceivesInput.LAST. FIRST is default, if LAST is specified then
any custom input processors will receive first dibs on any input, and
only if it is not handled, that is the input handling method in the
InputProcessor returns false, then Nifty will receive it.
Merge pull request #266 from 3xp0n3nt/gdx-input-multiplexer

Add LibGDX input forwarding customization.
Add music looping to GdxMusicHandle.