Improve weston_surface and weston_view identification for debugging

When debug prints need to identify a weston_surface or a weston_view, they print the raw pointer with %p. 64-bit pointers are hard to read for humans, and even harder to compare for correlating debug messages. These pointers should be replaced with more human-friendly IDs.

Add a uint32_t counter in struct weston_compositor for generating such IDs, store them in weston_surface and weston_view, and use them in debug prints.

Pointer values may get re-used if the struct is freed and then another is allocated at the same address. OTOH, uint32_t may wrap around, but I suspect that is rare enough to not be a concern. If it proves to be a concern, we can easily upgrade to 64-bit, but then again the point of having it for human-readability is lost anyway.

Also better ideas for making it easier to identify surfaces and views are welcome. Note, that Wayland protocol object IDs are not unique in a weston_compositor, they are only unique for a client and they get aggressively re-used.

We could also consider a string naming scheme, e.g. <client-id>:<item-id>:<protocol-object-id> where client-id would be zero for items that were not associated with any client when allocated, item-id would come from a per-client counter, and protocol-object-id comes from the corresponding Wayland protocol object ID if there is any (e.g. wl_surface ID for weston_surface and weston_view). This would be different from the description string we already have for weston_surface. This could be stored as a string in the item.