We do them in the top callers, so that we don't have to try/catch
everywhere.

This was breaking the loading of custom icons with previous commit,
because we ended up stopping loading of normal icons when a custom icon
was about to be loaded.

If an overlay icon is loading it must not cancel any operation for other
icons, instead we should just proceed or we'd block the loading of all
the icons.

It's not worth adding another list to keep track of icons by their type
because, we want loading any icon to stop the previously started
operations, whether they're attention or normal ones, while overlay ones
are so uncommon that we don't really care much if we require updating
them multiple times.

Since we're recreating a cancellable for each icon request we should
ensure that when starting an async operation we preserve using the same
cancellable for all the reqeusts or we may eventually continue on an
operation after that it has been originally cancelled (because the new
cancellable is actually used).

We're now overriding it in settings

In some cases we can't update the layouts promptly, so mark the menu
ready only when it really is.

In some cases menu can change path or being removed, so try to track
this case by keeping the menu populated only while the client is ready.

For some properties (Status and Icons theme path) we get the changed
value as the status argument, so in such case we don't have to perform
further dbus calls but we can just emit the change promptly, or wait
for next update if one is already pending.

This is also fixing a nasty issue we had that was causing icons state
not being updated when they were moving to passive just before removing
the indicator from the bus.

This is happening in electron apps that provide an option to toggle the
indicator (such as ferdium): when turning it off the old indicator sends
us a status change to passive and the object is immediately removed from
the bus. This was problematic for us because we were trying to update
the state again from an object that had been removed, leading to dbus
errors.

Closes: #348

In some cases indicators may disappear and we don't need to keep track
of them anymore, so let's just try to check if they're replying to our
dbus calls after some changes, and if they don't we just destroy them.

Be consistent so we can sure they always match.

Gjs does it already for us

Use indicator destroy signal as single point for removing items from
our tracked indicators. And ensure that when an indicator is destroyed
we notify it via dbus-signals.

In KDE applications we use the name watcher to monitor applications
indicator presency, however we did not consider that in our logic
properly.

This fixes the case in which a Qt applications (i.e. Telegram) hides an
indicator from settings. Before of this we used not to remove it, even
though was not working anymore.

We should ensure that we have it, or just fail otherwise.

So we force reloading them

We need to handle it at upper levels, not in an utility function

As per previous commits, if the properties checking fails we'd now
switch to check-alive checks, that may lead the indicator to be
destroyed if it doesn't reply anymore.

If the icon is not visible, tracking its menu items it's pointless and
just consumes resources, so let's just remove all the items when hidden
while set them back when visible again.

If the indicator is hidden, there's no need to do icon updates, we can
just do them once we're back to business.

This ensures that we're going to destroy the actual icon all the times.

So we are consistent with tray icons too

In case logging is disabled for the extension or in general, there's no
need to do C calls, as we can handle this way earlier in JS scope.

No need to have a global cancellable for this, as we need to track icon
updates that may happen at the same time.

We only want to stop icon updates that act on the same final icon

It may be legit to have null icons, but this is an issue only if due to
an actual error, so filter them more.

When using brute force also try to use the actual service name if we can
find it.

When computing the unique ID we should also consider the service name,
as that's used in some cases as unique-id.

This fixes an issue that was causing us not to remove some indicators
when disabling the extension, leading to a double-destroy.