When handling the combined visibility of the edited prim, the code did not work when the prim was directly under the stage.

More precisely, the ProxyAccessor design did not support accessing properties of the absolute root node of a stage. Normally, this would not be a problem since that prim does not have attributes, but for Edit-as-Maya, the combined visibility assumed it could create a SdfPath to the associated property, which is imposible for the root prim.

The solution is to modify the ProxyAccessor code to avoid creating the SdfPath to the property and instead keep th eprim path and property name separate in the code. Unfortunately, the way the proxy accessor works is by encoding the full path of the property ("prim.property") in the Maya attribute name. So we "cheat" by creating impossible names for the root node. For example "/.compositeVisibility". This requires never treating the Maya attribute name as a SdfPath, but spliting it ourselves into a SdfPath and a property name. We do this to be backward compatible.

Before the introduction of compositeVisibility, the only attribute that was accessed on the stage root prim was its transformation matrix, at the code cheated by *not* providing a property name and having the code magically knowing that when there is no property name, it meant the transform matrix was intended. Again, this magic is kept for backward compatibility.

While at it, some code cleanup was done to use an explicit structure instead of a std::tuple to make the code more readable and easier to maintain. (std::get<3> make is unclear what is being accessed...)