Refactoring of framebuffer: Unified way to set render targets, added level field. - #1401

There are many places in the codebase where the deprecated methods are still used.

For instance, setDepthBuffer() is used in jme3-core, jme3-desktop, jme3-examples, and jme3-effects. But setDepthTarget() (its replacement) has no javadoc and is only used in a single example (TestMultiRenderTarget).

The shortage of examples (and javadoc) makes it difficult to understand how the replacement methods are meant to be used.

It's difficult for me to write this paragraph, given that I didn't complain a year ago, but I've been using this API recently and had a few things I'd propose for potential changes.

1. Remove the FrameBuffer prefix from inner classes, preventing things like FrameBuffer.FrameBufferTextureTarget adding verbosity.
2. get/set/add: If you can get specific buffers and set used to overwrite the old one, can we maybe add an api to overwrite specific targets (if that is even supported / makes sense?)
3. FrameBufferTarget.newTarget and the private constructors. When I search for RenderBuffers and find e.g. the FrameBuffer.TextureTarget, then I probably expect to construct it via new TextureTarget, or at the very least with a TextureTargetFactory or -Builder. In this case however, it's not justified to require some complex factory, given that we only look at one simple parameter each. I understand that someone may want a convenience method to pick the right class based on the parameter, so one does not need to call new on the class, but I don't understand preventing regular use.

Now the problem is that this is already part of 3.4, but what do you think of it in general?

Is the final question addressed to me, to @riccardobl, or to both of us?

to everyone of jme. Especially depending on if it's just me or not