Add two examples #1 and #3

[bakpaul]

In this you have two examples in

baseNodeModifier.py
baseNodeModifier2.py

The first one is the case 3 which is the one I like the less because as a user you'll have to first think where you want to add the modifier instead of thinking on who you want to apply it. Although in my mind the first one is neither required nor obvious in most cases (see comment in the scene description part at the bottom of baseNodeModifier.py)

The second one is the one I prefer (it is case 1 with a tweak). Here the user creates the modifier, then apply it to the node he wants to apply it to. And then, after that, only if he cares or knows that he can do it, he specifies the "holder" in which to place the modifier. If none is given then a 'logical' one is selected for him.

Plus I have implemented (well nearly as this is currently a vector of string because of the lack of bindings) the two ways link to modifier and to node on which the modifier is applied. If you launch the files as mains you'll launch the scene and see in both the entity and the modifier a new data (called modifiedBy for the Node and modified for the modifier, holding relative paths)

PS: the two ways link might only work for the baseNodeModifier2.py but as it is independent from the solution chosen , it'll be easily adapted to the other one

[damienmarchal]

Why ?

[bakpaul]

Wrong copy/past TBH, thank's !