Windows: cm_GetSCache avoid holding cm_scacheLock

Windows: cm_GetSCache avoid holding cm_scacheLock

cm_GetSCache used to hold cm_scacheLock write-locked from
start to finish except that it didn't.  There were several
places where cm_scacheLock was dropped and reacquired due
to lock ordering requirements.  Unfortunately, this has
two problems. First, the function isn't very fast in the
most common case since cm_scacheLock is write-locked for
the search for an existing FID.  Second, there is a race
that results when cm_GetNewSCache() drops the cm_scacheLock.

To make things faster, use a read-lock for the common case.

To avoid the race, if the FID cannot be located, call
cm_GetNewSCache() first and then obtain the cell and volume
information.  Then perform a second lookup for the FID while
holding cm_scacheLock write-locked.  If we lost the race or
there was an error obtaining the cell and volume info, put
the new cm_scache_t back onto the end of the LRU queue.

Change-Id: Idb94275d23c160ee0a2dc8fdcfd0f09506ecb2d3
Reviewed-on: http://gerrit.openafs.org/6003
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>