[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)
[DVDDemux] Allow for larger difference in dts and pts of packet

If video does not start on an I frame, you can get a significant difference
in pts and dts values for the first frame. I've got two videos where they
differ by more than 0.1s.

In this case, we end up setting pts=0 and leaving dts alone (which may be minutes away).
This gets through to GPU on Pi, and it tends to stall waiting for this difference to elapse.

I'm not sure what the largest difference can be, but 0.5s feels completely safe.
I'm not sure of any problems increasing this will cause.
Making JSON-RPC accept more content types

According to the RFC for JSON-RPC over HTTP at
http://www.jsonrpc.org/historical/json-rpc-over-http.html
"Content-Type SHOULD be 'application/json-rpc' but MAY be
'application/json' or 'application/jsonrequest'"

This patch fixes HTTPJsonRpcHandler to allow for any of those three
content types when accepting JSON-RPC HTTP requests.

This also fixes compatibility with the popular Python library jsonrpclib
which uses the application/json-rpc content type.
[osx] fixed, stray touch under xcode3
fixed, when compiling for native, tarball was saved in wrong place
DVDAudioCodecFFmpeg: do not reopen the resample context for each frame.

There is no point in doing this and opening an already opened context
leaks memory in lavr.
configure, external ffmpeg: do not check if libavcodec contains vdpau functions.

it will fall back to other methods if not present and we have no guarantee that the libavcodec version we build against will be the same we run with (except it has the same ABI but ff_vdpau symbols are not part of the ABI).
[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
[jenkins] - disable the need of signing for ios/atv2 on jenkins