first version of BatchRenderDevice implementation
BatchRenderFont implements RenderFont added to fix compiler issues
finish BatchRenderDevice and LwjglBatchRenderBackend
Conflicts:
	nifty-examples/src/main/java/de/lessvoid/nifty/examples/defaultcontrols/ControlsDemo.java
Batch API JavaDoc cleanup
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.
Conflicts:
	nifty-core/src/main/java/de/lessvoid/nifty/elements/Element.java
new examples and explanation added to logging.properties
fix failing tests
we need to mark all images as unloaded in unloadScreenImages
BatchRenderer Image Management corrected for newly loaded screens

When a new XML file is loaded with nifty.fromXml() all existing screen
based cache information in NiftyImageManager will now be removed. This
fixes an issue that old images (referenced by old screens with the same
id) are still uploaded to the texture atlas even though they are not
needed in the newly version of the screen with the same id.

The same fixes have been applied when screens are being removed
dynamically with nifty.removeScreen(). So now everything that's being
uploaded to the texture atlas is really only the images that are needed.

It was possible that the onEndScreen() event could be
triggered from a nifty.render() call which in turned would call the
niftyImageManager to unload all the images. And then when the rendering
continued the dynamic upload mechanism was activated that would upload
the images again since they could still be references from other render
calls :) To prevent this issue the onEndScreen stuff is now being
delayed as an EndOfFrameAction which prevents this issue.

So finally with this commit the whole batched renderer and extended
image manager business should be in place correctly.
Conflicts:
	nifty-core/src/main/java/de/lessvoid/nifty/screen/Screen.java
Extract NiftyImageManager differences between batched and non-batched

additionally this fixed non batched rendering which the
NiftyImageManager broke
Conflicts:
	nifty-examples/src/main/resources/logging.properties
shut off spamming by changing logging from INFO to FINE, closes #65
Conflicts:
	nifty-core/src/main/java/de/lessvoid/nifty/NiftyStopwatch.java
	nifty-core/src/main/java/de/lessvoid/nifty/effects/impl/Hide.java
	nifty-core/src/main/java/de/lessvoid/nifty/effects/impl/Show.java
workaround for issue #73 added

The KeyboardInputEvent constructor sets the character instance variable
to 0 when the control-key is pressed. This prevents characters you can
only reach with the help of control and alt, like AltGr+Q on Windows to
insert a @ character for certain keyboard layouts.

To prevent this issue I've now removed the "if (controlDown)" check in
the constructor. This means any character code pressed while any of the
special keys is down (alt, shift, control) will be processed as
a regular key.

However, the InputMapping implementation, f.i. TextfieldInputMapping
will handle some control+key combinations like ctrl+A or ctrl+C and so
correctly and will prevent any character input into the textfield in
that case. Other, unhandled combinations will still find it's way to
the textfield which is not quite right but shouldn't do any harm. For
instance you can now press ctrl-P and a you would see "P" in the
textfield.
improve renderEngine.createImage() JavaDoc since it was changed in 1.3.3
jglfont-core-1.2 added to enable embedded textcolor for batched renderer
console.fnt removed from examples since the font is in the style-black
LwjglBatchRenderBackendCoreProfile: BatchRenderBackend for Core Profile
Conflicts:
	nifty-examples/src/main/resources/logging.properties
method markBatchRenderImageAsUnloaded() added to NiftyImage

This method allows you to modify a backing texture externally and then
notify Nifty that you've changed the texture. Nifty will then upload the
image to the texture atlas the next time the image is accessed. Without
this method Nifty would never know about the change of the texture and
would never update the texture atlas with the updated texture. This
method is specific to the new BatchRenderer.