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.