announce: rename the host on a probe conflict instead of giving up

[LorbusChris]

When probing finds another responder already using our host name, umdns prints a
message on stderr and returns from the announce state machine without ever
reaching STATE_ANNOUNCE. It then never announces its host records or its
services, never retries, and stays that way until restarted.

The init script does not capture stderr, so nothing reaches the log either: the
daemon is running, the services are still listed by ubus call umdns announcements, port 5353 is still bound, and there is simply nothing on the wire.

RFC 6762 section 9 asks a responder to pick a new name and probe again. Do that:
append a -N suffix and restart probing, up to HOSTNAME_MAX_SUFFIX attempts,
keeping the old behaviour of giving up once those are exhausted. The suffix is
derived from the unsuffixed system host name, so repeated conflicts give host-2,
host-3 and not host-2-2. Services that carry no explicit hostname or
instance follow the rename automatically, as they point at the globals.

Since the host name is global while the announce state machine is per interface,
all interfaces probe again for the new name rather than announce the old one.

get_hostname() is called again on every service reload, so it now only resets
the suffix when the system host name itself changed, letting a name picked to
resolve a conflict survive an unrelated reload.

Tested against avahi-daemon holding testrouter.local:

the host testrouter.local already exists, renaming to testrouter-2.local

and umdns goes on to announce testrouter-2.local, where before it announced
nothing. Builds clean under the project's -Werror.

Note this only changes what happens once a conflict is detected. Detection
itself is unchanged and remains cache based, so a responder that answers the probe
but never announces unsolicited can still be missed.