jglfont-core-1.1 dependency added
Huge BatchRenderDevice update with better texture atlas management

Ok, this was more work than anticipated but it should handle the texture
atlas a lot better now. Here is a short explanation - I really need to
blog about all of that stuff soon in more detail tho ;)

So basically there is a texture atlas of a certain size. The actual
size can be adjusted by the user. At the moment all of the examples I've
modified to use the batch renderer uses a 2048x2048 texture which seems
to be more than enough for all of the standard examples I've tried.

This texture atlas is now filled with images for the current active
Nifty screen. So that all the images required by the current active will
be part of the texture atlas. To do that Nifty keeps track of which
image belongs to which Screen when it reads a XML file or when a Screen
is created with a Builder. This tracking is done for all loaded screens
and even for images that are dynamically created with
Nifty.createImage(). These dynamic images will be added to the current
active screen. If there is no current active Screen then the images will
still be loaded and uploaded to the texture atlas at the first
render access.

But in general Nifty will upload all images that are required for the
current screen into the texture atlas when a new Screen is
started. Consequently when a screen ends the texture atlas is being
reset to an empty one.

Nifty already implemented a reference counting mechanism to keep
track of already loaded image resources. This was used to prevent
loading the same image multiple times and it is still being used for
this purpose. However, the process of loading an image is now separated
into two steps:

1. the actual image data is loaded into whatever image representation a
BatchRenderBackend supports (the example implementation using native
LWJGL will simply load an image file into a ByteBuffer) and

2. the loaded image data is put into the texture atlas at a position
that Nifty decided when it's time for this image to be a part of the
current screen.

When an image is accessed dynamically while a screen is running it will
be uploaded at the time of the first access. For best performance static
images - or at least ones that Nifty knows about before the screen is
started - should be preferred so that Nifty can upload them to the
texture atlas at the time the screen starts and not while the screen is
already running. Although I think you can get away easily with a couple
of image uploads if you don't access multiple images in a single
render frame.

All of this is required to keep only the currently active images in the
texture atlas if possible. This should work quite well for most use
cases although it's still possible to use up all of the available space
in the texture atlas. The batch renderer still should provide much
better rendering performance and should work well when being carefully
used.

List of changes in this commit:

- lots of changes to the image managment in NiftyImageManager especially
tracking of the screen an image is attached to
- renderEngine.createImage() now requires a Screen instance
- removeFromTexture() and clearAtlasTexture() methods added to
BatchRenderBackend
- TextureAtlasGenerator now supports removal of images as well
- BatchRenderImage now supports upload() and unload() methods
- font resource loading now attached to upload() and unload() as well

Attention:

It is unlikely but still possible that some of these changes will break
existing code especially when this code uses internal methods like
renderEngine.createImage() instead of nifty.createImage(). These errors
should show up as compile errors and should therefore be easily fixed
though.

I'm sure there are other more hidden issues but I've really tried to
keep the changes at a minimum so in general it should be fine.
new examples and explanation added to logging.properties