radial layout + animation speed

A "plain" radial layout is added. Plain as in: not smart yet :) the
nodes don't expand yet into free neighbour-space, they just get fewer
and fewer space the longer their ancestry. Planning to build a
RadialSmartLayout...
Oh and please note the way i am "faking" the levelwise and nodewise
animation at the end of the RadialPlainLayout class :) I couldn't track
when the nodes are doing their placement (because graph knows node but
node does not know graph, which i (currently) think is a good & elegant
architecture) because they do it "decentralized themselves" - so i faked
it afterwards by saving their positions but putting them back to 0,0 and
then position them anew, this time under control and with keyframes
added levelwise and nodewise.

Animation speed (as in thread.sleep(this value)) can now be changed at
any time. If no animation is currently happening the change of that
slider will cause the latest animation to be repeated at the new speed.
If the slider is used during an animation the speed will adapt right
away.
Made it possible to change the layout options in any animation mode. The animation thread is now interruptible and stopAnimation will interrupt it.
Extracted most of the animation logic into the Animator class. The Animator is now a thread that will run all the time (so no new thread creation for each animation). It's created and injected by the Driver on the start.
The Interface can now be used while the animation is running.
Take the node size into account for positioning the nodes.
save points as hashmap & AnimationPostproduction

As planned in #8 i got rid of the clunky searchPointByID help-method
through using a HashMap with the node/point IDs as keys.

Giving weight to the conceptual element of caring about the
layouting-animation AFTER the actual layout-computation has been done.
This was present in the radialPlainLayout class before but giving it an
extra-class elevates it's conceptual status and may pave the wave for
adding other "postProduction" layouting like a strict left-to-right one
for instance or a depth-first kind of one that starts from the branch on
the very left and works its way to the right. Or starting in the middle
and working towards both sides simultaneously? Cool things possible i'd
imagine.
Not sure yet if it would be better as a static class or by implementing
an interface like Sanjo did with the layout algorithms...
Moved src to root directory.
Updated. gitignore.
Reformated code with IntelliJ default code style.