xdg-shell: clarify xdg_surface creation semantics regarding buffers

this change ensures that the client will set its initial state
before performing any drawing, ensuring that there is no mismatch
when creating a surface with a non-default state
(eg. maximize, fullscreen, ...)

looking at the following event flows:
1) wl_surface.attach, wl_surface.commit, xdg_shell.get_xdg_surface

2) wl_surface.attach, xdg_shell.get_xdg_surface, wl_surface.commit

3) xdg_shell.get_xdg_surface, wl_surface.commit, xdg_surface.configure,
   wl_surface.attach, wl_surface.commit

only 3) is now valid, while 1) and 2) will trigger errors as a result
of handling buffers prior to creating the xdg surface

Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>

unstable/xdg-shell/xdg-shell-unstable-v6.xml

@@ -126,14 +126,12 @@
       them, and associate metadata like title and app id.
 
       The client must call wl_surface.commit on the corresponding wl_surface
-      for the xdg_surface state to take effect. Prior to committing the new
-      state, it can set up initial configuration, such as maximizing or setting
-      a window geometry.
-
-      Even without attaching a buffer the compositor must respond to initial
-      committed configuration, for instance sending a configure event with
-      expected window geometry if the client maximized its surface during
-      initialization.
+      for the xdg_surface state to take effect.
+
+      Creating an xdg_surface from a wl_surface which has a buffer attached or
+      committed is a client error, and any attempts by a client to attach or
+      manipulate a buffer prior to the first xdg_surface.configure call must
+      also be treated as errors.
 
       For a surface to be mapped by the compositor the client must have
       committed both an xdg_surface state and a buffer.