nss-mdns standard installation contingent on AVAHI_DAEMON

Sorry for the delay; my first PR, I had to figure out how etc., as well as do a fresh build in this topic branch and test it again. This relates to issue #3187 and PR #3311 (which I suppose is now a competing approach) :-} I've been running this since last week, but because of last night's discussion, which I caught just as I was going to bed, I thought I'd better at least make a PR of it so people have something to discuss and test.

This adds a completely standard installation of nss-mdns to OpenELEC. It simply installs nss-mdns in the default manner and makes the required change to the *static* ```/etc/nsswitch.conf``` file. Its building is controlled by the AVAHI_DAEMON flag, so the two would be built, or not built, together.

As such this represents the simple, minimal, this-ought-to-work solution to the problem. As it *does* work for me, I think it needs some wider testing so we know for sure it causes problems elsewhere that might require the complicated dynamic switching of ```/etc/nsswitch.conf``` as avahi-daemon goes up and down. As others have noted, that's a bit hairy, making sure it never gets into a bad state, so I really do think it's worth being sure we need to do it at all. :-)

What I find, with this:

With avahi-daemon running, it all just works, and OE is able to resolve .local as expected. DNS names also continue to resolve just fine.

With avahi-daemon not running, DNS names continue to resolve just fine, obviously (as you'd expect) .local names do not resolve.

It's my understanding that nss-mdns solely uses avahi-daemon for mdns resolution. If it isn't running the nss-mdns lookup just returns immediately. Earlier versions shipped with an internal mdns resolver (still available as a build option, not used here). I wonder if that used to be the, or a, cause of mdns issues back in the day that still makes people suspicious of it now. :-) Because it would have continued trying to work even when the user had disabled avahi-daemon, which they presumably would have done because, for whatever reason (multicast blocked? dns config issues?) mdns already wasn't working on their network.

IPV6: I'm not sure if this is at all relevant but as people are talking of installing mdns4 only...

I have ipv6 on my local network. With the OE network connection configured ("auto") to use it, everything works, eg: ```ping host.local``` (ipv4) begins without delay, and ```ping6 host.local``` (ipv6) also begins without delay.

One slight *possible* issue: ```ping <fqdn>``` sees a short delay before pinging starts, whereas ```ping6 <fqdn>``` again starts without delay. It looks like it may be a name resolution delay, but eg: ```getent hosts <fqdn>``` returns ipv4 results immediately.

If ipv6 is disabled on the network connection, this delay pinging ipv4 hostnames disappears completely.

So I'm not sure what's going on there, or whether it relates to nss-mdns at all, given that there's no change to this behaviour if avahi-daemon is switched off. I'd need to reinstall a vanilla OE to check if that shows the same behaviour on my network.

Above testing done with ```PROJECT=Generic ARCH=x86_64``` on a zotac/nvidia htpc, and ```PROJECT=RPi ARCH=arm``` on an RPI.

It's such a default installation, the libnss-mdns libraries are just installed directly to /usr/lib. I see from #3311 what may be the more standard approach? to have versioned library names in /usr symlinked?
well, again, the approach here is to first do it the utterly standard ought-to-work way and see what breaks. :-) Obviously mdns (not-minimal) comes at the end after dns, and it *is* possible people out there may be using mdns in the more exotic ways that would handle. I agree those would be the edge case, but again, let's see if the default actually causes problems to mainstream users before deviating and cutting out functionality. :-)