[FIX] Allow more paths in CFileUtils::RemoteAccessAllowed

As found by @Voyager1 there's some more path that should be allowed since they are used by addons or internally.
Perhaps more are needed, and perhaps a way to differentiate UPNP / Remote JSON / Addon JSON is needed.
[depends] - bump mdnsresponder to 379.37
[zeroconf] - add new hostname field to the service class - its needed by mdns
[mdns] - fix service resolving when using mdns-embedded
- don't call our dnsresolver in the callback but try it in the zeroconf thread instead
- if that fails (as it does in some networks/platforms where gethostbyname doesn't resolve .local. domains) - fallback to the mdns resolver
[mdns] - enable zeroconfbrowser via mdnsembedded - as the browsing/service-resolveing issue is solved now
Merge pull request #2864 from Memphiz/mdns

[mdnsembedded] - fix zeroconfbrowser
jsonrpc: fix property values returned by Player.GetItem
jsonrpc: use "song" as default value for "type" property
cosmetics in CFileOperations
jsonrpc: fix "filetype" property being (unexpectedly) returned for Player.GetItem et al.
Merge pull request #2828 from Tolriq/fix_remoteaccess

allow more paths in CFileUtils::RemoteAccessAllowed (fixes some addons and JSON-RPC clients)
[osx] fixed, stray touch under xcode3
fixed, when compiling for native, tarball was saved in wrong place
[FIX] Faster and clever way to fix e0ec520d00

As title say faster way to correct the filetype field behavior.
(A lot since std::set use key as index while CFileItemList.Get on filename needs locks and tons of overhead, not talking about the size of parameters compared to a large directory).
Merge pull request #2871 from Tolriq/faster_fix_filetype

jsonrpc: faster and better way to fix "filetype" property than e0ec520d00