Verify that code behavior is not changed.
* Notice that inheritance order matters. If the IGUIObject is not constructed first, the IButtonBehavior base class will call RegisterSetting on the uninitialized GUI object.
* Notice that the JSInterface_IGUITextOwner removal is necessary, because the IGUIObject* stored using JS SetPrivate cannot be statically cast to IGUITextOwner* since they're not inherited anymore. (`static_cast from 'IGUIObject *' to 'IGUITextOwner *', which are not related by inheritance, is not allowed`)
* Notice that we can cast the `IGUIObject*` to `CText*` and then operate from there, which is strictly more correct since the previous GetTextSize function only return the size of the first CGUIText, while it can store multiple. So every leaf class can decide more closely which values it wants to return.
* Notice the IGUIObject::foo function calls may not be translated to m_pObject.foo calls, because that would not call the base class function but the overriding function of the leaf class.
The most simple and failsafe alternative is to make it a responsibility of the leaf class to call the inherited functions when there are multiple of them.
So this is the greatest behavior change in this diff and it can be verified by going through all classes of IGUITextOwner, IGUIScrollBarOwner, IGUIButtonBehavior and ensuring that they are called from the classes that inherit them. The classes that inherit them are identified by these classnames appearing in the class definition in the header.
* Observe that the functions are ordered consistently and in a way that minimizes fragmentation of virtual function calls on different bases.
* Notice that IGUIButtonBehavior would be much cleaner if it would inherit IGUIObject. But that would break the symmetry. The approach should be scalable, so that developers can chose from many more base classes to inherit from. For that to become possible, none of them should be inheriting IGUIObject, thus IGUIButtonBehavior neither.
* Notice `IGUIScrollBarOwner` doesn't use the object yet, but it seems probable that it will be used soon, as it is in the inheritance chain. The benefit of not passing the IGUIObject& but the CGUI& is avoiding one GetGUI each draw call and reducing the number of lines in this diff. But passing IGUIObject& also means that the base classes are more symmetrical and consistent.
* Notice that all function implementations in the three base classes are moved to the cpp file.
* Ensure that there are no remanants of the removed in rP22596.
* Ensure that all functions have appropriate yet consistent comments.