[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.
[win32] use MSBuild.exe or devenv.com (if available) in BuildSetup.bat to get verbose console output
[win32] cosmetic in BuildSetup.bat
[jenkins] - do the mingw build in a backgroundthread and echo "." on the foreground thread for giving continuous output to the jenkins slave - should fix the disconnect issue on win32 slave
Add #include guards for HAS_PYTHON

This fixes compile of Addon.cpp and Weather.cpp if HAS_PYTHON is not defined
Remove Python dialogs when compiling without Python

cherry-picked from https://github.com/plexinc/plex-home-theater-public/commit/f76df3e72
Retain type safety by using const_cast instead of C-style cast
Merge pull request #2868 from Montellese/win32_msbuild

[win32] make BuildSetup.bat et. al. more robust for jenkins builds
[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.
[osx] fixed, stray touch under xcode3