[win32] - nfs fix

This is a special version of the nfs fix - just for gotham (hence the PR to Gotham branch).

What it does

1. Revert the libnfs downgrade back to 1.6.2
2. Make the issue with the dropped library during scan unlikely to happen

The reason why @bossanova808's library was dropped with libnfs 1.6.2 was the excessive hammering of the mount_getexportlist call. This call was intended to be fired only when the server we are connecting to changed (which is only the case in environments with multiple NASs - very rar scenario). Due to a bug in XBMCs nfs code this call was called whenever the exportpath of the requested file changed. In the setup of bossanova there are something around 8 exports he is serving via nfs. During scan we switch between those exports a dozens of time.

mount_getexportlist opens a socket - queries the export list from the server - closes the socket. The problem is that sockets are lingering after close for something like 120 seconds. This means that those sockets are still "taken" and new sockets with the same src port are denied. This is what happend here. We exhausted the sockets (libnfs determines the source ports on its own by some funky algorithm and limits it to 512 sockets or less!) because of hitting this collision.

The workaround for gotham is to not clear the m_exportList in clearmembers (which is called whenever the exportpath or hostname changes) - but instead let splitUrlIntoExportAndPath do its job and determine on its own if he needs to fetch a new list (based on the criteria of a changed hostname). (before the clear of the list leads to the mount_getexport call because m_exportList .IsEmpty() was true then).

This is my last try to calm down the windows nfs crowd. Up to the RMs.

For master there will be a another PR (hopefully soon) which won't clear m_exportList for all platforms (not only windows) and also use a "fixed" libnfs which is immune against the socket exhaust. The real fix for the latter is still to be found (first idea is to deactivate lingering of sockets completly on windows - means no gracefull socket close - but socket kill).