Renamed the notion of handler classes to plugin classes in the Studio Python API

This change refactors the Python API to use the term "plugins" instead of "handlers" for classes containing decorated handler methods. The term handler is still used for an annotated method of a plugin class that handles a specific message type. Also improved some documentation.

PiperOrigin-RevId: 962150099
Change-Id: I34a8cc410cd784b088605490cfa3baccea5c9e71

python/mujoco/experimental/studio/viewer_app.py

@@ -11,7 +11,21 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
-"""Viewer component of Studio."""
+"""Python implementation of the default Studio Viewer application UI.
+
+The class can be used as a plugin to run the full Studio Viewer application in
+Python.
+
+Architecture:
+  ViewerApp provides the full default UI/UX as a viewer-side plugin. This class
+  is viewer-agnostic and as such does not own camera, vis_options, or perturb
+  objects (these are provided by the viewer).
+
+  Viewer classes (NativeViewer and WebViewer) own the renderer, camera,
+  vis_options, and local deep-copied model/data used for rendering. The sim side
+  owns the physical simulation and pushes state snapshots to the viewer via
+  ViewerHandle.sync().
+"""
 
 import copy
 import dataclasses
@@ -32,8 +46,8 @@ from mujoco.experimental.dear_imgui import dear_imgui as imgui
 class ViewerAppInitEvent(messages.Event):
   """Lifecycle event dispatched once when the ViewerApp is initialised.
 
-  Handlers that need access to the ViewerApp should handle this event
-  and cache the reference.
+  Plugins that need access to the ViewerApp should handle this event and cache
+  the reference.
   """
 
   viewer_app: 'ViewerApp'