Enable property un-assign for QtState

A new and easy way to manage objects is to bind them to a states.

state->assignProperty(object, property, value)

That way the state will set the property of the object on state enter.

This is very convenient, but has a drawback. Its unreversible. Once bound there is no unbounding until the state is destroyed.

It is unfortunate, because there times when an object needs to be controlled by the state only for a time and/or be able to switch witch object controls the desired properties.
For instance: An icon and a drawer that takes icons in. The drawer will have open and close state. Its desirable that the icon will sit unaffected on a desktop, not controlled by any state, until dragged into the drawer. Then it will become part of the drawer state machine and be driven by it. When the user drags out the icon from the drawer, it will lose its connection to the drawer state and the relevant properties are no longer controlled by it.

This scenario is impossible for now, because one cannot break the state-controls-property connection.

What is needed is state->unassignProperty(object, property, value) (or some better name) func. that will unregister the object from the sate.
Implementing this seams trivial, because the assignment is little more than a list.append() of a property wrapping object. (Also the State dtor just deleteAll that list, so I guess there will be hardly any ill effects from removing an item from it).

—
I must note there are workaround for this problem. The most "right" one is wrapping the property setting job into a "private" (to the object) state(s). Then one has the option to choose when, if and by who this state is activated thus activating property assignments. The solution might be "right" but is not trivial to come up with, and has as noticeable drawback (beyond the obvious one - introducing new states ).
In our example if the drawer sets the properties of an icon directly - it has control of "what does it means to be in the drawer" (choosing which props. to set). Now, with the new solution, it only triggers the icon's "property setting state". In a way the icon decides "what it is to be in the drawer". This might or might not be a good thing, but should not be obligatory - after all, in a static solution (the icon is in the drawer once and for all) it is the drawer who sets all directly.