* On lines where the variable type is obvious from inspection, avoid repeating the type using auto.
* When possible use a ranged for loop instead of begin() and end() iterators
The problem is caused by tracking of editing object placement
introduced in b25ad5e085a42800c0ebd7a507233f081fcee7ef.
After this commit, any editing object can disable placement tracking by
calling Gui::Document::setEditingTransform() inside either
ViewProvider::startEditing() or setEditingViewProvider().
The link support means that an object can now appear in more than one
places, and even inside a document different from its own. This patch
adds support for in-place editing, meaning that the object can be edited
at correct place regardless where it is.
See [here](https://git.io/fjPIk) for more info about the relavent APIs.
This patch includes two example of modifications to support in-place
editing. One is the ViewProviderDragger, which simply adds the dragger
node to editing root node by calling
View3DInventorViewer::setupEditingRoot(dragger). The other much more
complex one is ViewProviderSketch which calls setupEditingRoot(0) to
transfer all its children node into editing root. ViewProviderSketch
also includes various modifications to command invocation, because we
can no longer assume the active document is the owner of the editing
object.
This patch also includes necessary modification of the 'Show' module to
support in-place editing.
