Currently requires a dirty workaround to prevent tray icons with
different depths from crashing

The client window has to be added to the save set after it has been
reparented. Otherwise if the reparenting fails weird stuff happens
(windows in the save set have to be child windows of windows created by
the current connection).

The wrapper window must define a border background if the depth doesn't
match the parent window.

If an exception is thrown earlier, stopping the eventloop produces an
error.

The tray window uses the pixmap of the bar window and clears window
content on every update.

Each tray client is directly reparented to the bar window. This saves us
the hassle of having to configure a basically useless tray window and
keeping its background pixmap in sync.

The only disadvantages are having to (un)map each client window
individually and calculating its position relative to the bar window
(which changes all the time) instead of relative to the tray window
(which only changes when clients are added/removed).

If the bar window (un)maps, the tray icons are automatically (un)mapped

The issue was that the event was for the wrapper window and that the
tray_client's move constructors didn't correctly copy over all data and
so when the m_clients vector grew, it corrupted the state of all
existing clients.

Used by clangd

tray_client::clear_window is called on expose events for the wrapper
window, thus it must not produce expose events for itself again.

Is used for trays defined through tray-position and nothing else.

Replaced with explicit reset function

The poll-loop could in theory swallow events which would not be seen by
the main eventloop

Not actually used anywhere

Not doign this. Using the desired background as the X window background
color would require us to always first check before using the pixmap or
cairo context.

They are noted in polybar#2689

Currently, we don't support 32-bit visuals and don't set
_NET_SYSTEM_TRAY_VISUAL

It is unclear what happens if the default visual (which is used as a
fallback if _NET_SYSTEM_TRAY_VISUAL is not set) is 32-bit.
In that case, we may need to explicitly use a 24-bit visual.

Unclear why it is needed, neither i3bar, nor stalonetray do delayed
notifications

The border size was not taken into account when calculating the tray
icon's y-position