client: Allow absolute paths in WAYLAND_DISPLAY

client: Allow absolute paths in WAYLAND_DISPLAY

In order to support system compositor instances, it is necessary to
allow clients' wl_display_connect() to find the compositor's listening
socket somewhere outside of XDG_RUNTIME_DIR. For a full account, see
the discussion beginning here:

https://lists.freedesktop.org/archives/wayland-devel/2017-November/035664.html

This change adjusts the client-side connection logic so that, if
WAYLAND_DISPLAY is formatted as an absolute pathname, the socket
connection attempt is made to just $WAYLAND_DISPLAY rather than
usual user-private location $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY.

This change is based on Davide Bettio's submission of the same concept
at:

https://lists.freedesktop.org/archives/wayland-devel/2015-August/023838.html.

v4 changes:

* Improved internal comments and some boundary-condition
  error checks in test case.
* Refer to compositor as "Wayland server" rather than "Wayland
  display" in wl_display_connect() doxygen comments.
* Remove redundant descriptions of parameter-interpretation
  mechanics from wl_display_connect() manpage. Reworked things
  to make it clear that 'name' and $WAYLAND_DISLAY are each
  capable of encoding absolute server socket paths.
* Remove callout to reference implementation behavior in protocol
  documented. In its place there is now a simple statement that
  implementations can optionally support absolute socket paths.

v3 changes:

* Added test case.
* Clarified documentation to note that 'name' parameter to wl_display_connect()
  can also be an absolute path.

v2 changes:

* Added backward incompatibility note to wl_display_connect() manpage.
* Rephased wl_display_connect() manpage changes to precisely match actual
  changed behavior.
* Added mention of new absolute path behavior in wl_display_connect()
  doxygen comments.
* Mentioned new absolute path interpretation of WAYLAND_DISPLAY in
  protocol documentation.

Signed-off-by: Matt Hoosier <matt.hoosier@gmail.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>