For local services use "localhost" in device URI of temporary queue

For local services use "localhost" in device URI of temporary queue

To print to a temporary CUPS queue for a discovered IPP printer the
client has to send an IPP_OP_CUPS_CREATE_LOCAL_PRINTER IPP request to
the CUPS daemon with the details for creating the temporary queue.
CUPS then calls its create_local_printer() function to actually create
the queue. This is already automatically and correctly done if the
client uses the convenience API of libcups.

The GTK print dialog does not use the convenience API though. It
displays all IPP printers for which CUPS can create temporary queues
correctly, but it fails on services which are only available on the
local machine and not on the network (loopback interface, "localhost")
whereas printing via temporary queue on network/remote services works
perfectly.

The problem is that Avahi advertises the local services not with the
"localhost" host name but with the network host name of the local
machine. The libcups convenience API functions can cope with this and
send correct device URIs with the "localhost" host name to CUPS and so
the temporary queue gets created correctly.

The GTK dialog wants fully asynchronous CUPS operation and throws the
libcups API completely overboard doing all by itself, and sending
incorrect device URIs with the network hostname for the local
services. CUPS creates the temporary queue with this URI then and
fails to do the get-printer-attributes request on the printer to
generate the PPD file, leaving the temporary queue in a non-functional
state.

This commit correct/works around this by checking whether the device
URI's host name is the same as the DNS-SD host name of the local
machine and if so, replaces the device URI's host name by "localhost".

Now one can select local services like IPP-over-USB printers or
Printer Applications in the GTK print dialog and printing on them
through an auto-generated temporary CUPS queue works.

I decided to fix/work around this problem in CUPS as we see that no
every print client developer uses the libcups convenience API.