color: define global_remove behavior

!14 (comment 2756612)
wayland#484



Toolkit authors are reluctant to handle the global removal, because on
most compositors the removal will never happen. OTOH, there is a
compositor author who wants to be able to change color-management
capabilities at runtime due to dynamically switching renderers.

This new wording strongly suggests the global is never removed to let
toolkits avoid all the code that removal tracking would need. Removal is
still technically allowed, but it is not generally expected that clients
would handle it.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

staging/color-management/color-management-v1.xml

@@ -73,11 +73,13 @@
 
   <interface name="wp_color_manager_v1" version="1">
     <description summary="color manager singleton">
-      A global interface used for getting color management extensions for
-      wl_surface and wl_output objects, and for creating client defined image
-      description objects. The extension interfaces allow
+      A singleton global interface used for getting color management extensions
+      for wl_surface and wl_output objects, and for creating client defined
+      image description objects. The extension interfaces allow
       getting the image description of outputs and setting the image
       description of surfaces.
+
+      Compositors should never remove this global.
     </description>
 
     <request name="destroy" type="destructor">