text-input: document behavior regarding multiple text-inputs

Currently protocol does not specify what should happen if multiple
text-inputs are created by same client, which is why this is more or
less undefined behavior currently in compositor implementations.

If client has created more than one text-input objects and surface owned
by the client is focused, then compositor must send enter event to all
text-input objects, in case of enable request however only one
text-input must be enabled per client per seat.
Signed-off-by: Bhushan Shah <bshah@kde.org>

unstable/text-input/text-input-unstable-v3.xml

@@ -94,6 +94,12 @@
         zwp_text_input_v3.disable when there is no longer any input focus on
         the current surface.
 
+        Clients must not enable more than one text input on the single seat
+        and should disable the current text input before enabling the new one.
+        At most one instance of text input may be in enabled state per instance,
+        Requests to enable the another text input when some text input is active
+        must be ignored by compositor.
+
         This request resets all state associated with previous enable, disable,
         set_surrounding_text, set_text_change_cause, set_content_type, and
         set_cursor_rectangle requests, as well as the state associated with
@@ -307,6 +313,9 @@
       <description summary="enter event">
         Notification that this seat's text-input focus is on a certain surface.
 
+        If client has created multiple text input objects, compositor must send
+        this event to all of them.
+
         When the seat has the keyboard capability the text-input focus follows
         the keyboard focus. This event sets the current surface for the
         text-input object.
@@ -321,7 +330,9 @@
         set.
 
         The leave notification clears the current surface. It is sent before
-        the enter notification for the new focus.
+        the enter notification for the new focus. After leave event, compositor
+        must ignore requests from any text input instances until next enter
+        event.
 
         When the seat has the keyboard capability the text-input focus follows
         the keyboard focus.