Refactor the Gizmo System

First a short Explanation about all the systems around the Gizmos work together:

Basically a user has two methods of changing the Gizmos/Lights:

• Changing the Light directly (Properties, Controls)
• Using the SceneComposer Tools

The SceneComposer Tools are easy: They change the Node we pass them as Gizmo. For this, we pass the special Class NodeCallback which allows us to hook into setLocalScale for example (since a PointLight has no scale, we have to convert this scale and call PointLight#setRadius.

If the Light has been changed directly though, we're facing a problem:
Currently we are using Controls (LightDirectionUpdate, LightPositionUpdate, ....) which check for the position (e.g.) each frame and when the position has been changed, we invoke NodeCallback#silentLocalTranslation (which does not trigger the hooks, which would lead to an endless loop)

Now my idea was to change these controls, because they do work each frame. The concern that they would be serialized is not valid, since they are attached to the gizmos which are seperate nodes which are not part of the current scene basically.

I've had the idea to just add proxy methods to the property panel which call JmeDirectionalLight#onSetDirection (this was actually my first approach at this) and then set the light's direction (or let that happen via the NodeCallback).

During the writing of this, it came to my mind that a user might want the Gizmos to react to his/her Controls. This means we're stuck with our current solution then.

What is your Opinion?
Either way I'm going to keep this Issue open to track the JavaDoc Status (either I'll Javadoc the Gizmos Package or add a document to docs/, actually I prefer the first).

Start by reviewing the Gizmos package, NodeCallback, the LightDirectionUpdate and LightPositionUpdate controls, and the property-panel path described in the issue. Resolve how direct light changes and SceneComposer changes should stay synchronized, then document the chosen design through JavaDoc in the Gizmos package or a document under docs/. There are no tests or specific files named in the issue.