sss_client: thread safe initialisation of sss_cli_mc_ctx
    
    In multi threaded application, it may happen that more threads will call
    function getpwuid(or similar) and sss client will not have initialized
    structure for fast memory cache. This structure is initialized just once.
    There isn't any problem with multi threaded application after successful
    initialisation.
    
    The race condition will happen if more threads try to initialise structure
    sss_cli_mc_ctx in function sss_nss_mc_get_ctx (ctx->initialized is false)
    It takes some time to initialise mmap cache: open file, get file size, mmap
    file, initialize structure sss_cli_mc_ctx. One of problems is that file with
    memory cache can be opened more times (file descriptor leak), but the race
    condition is with initialising structure sss_cli_mc_ctx. One tread will start
    to initialise this structure; another thread will think that structure is
    already initialised and will check consistency of this structure. It will fail
    because 1st thread did not finish initialisation. Therefore 2nd thread will
    return EINVAL and will do clean up in done section: munmap, close file and
    reset structure data. The 1st thread will finish an try to use memory cache,
    but structure was zero initialised by 2nd thread and it will cause dereference
    of NULL pointer in 1st thread (SIGSEGV) or dividing by zero in murmurhash
    function(SIGFPE)
    
    Function sss_nss_mc_get_ctx was split into two parts for simplification
    of locking and unlocking. The locking is used only in new static function
    sss_nss_mc_init_ctx. This function will not be called very often therefore the
    same mutex is used as in other nss functions.
    
    Resolves:
    https://fedorahosted.org/sssd/ticket/2380
    
    Reviewed-by: Michal Židek <mzidek@redhat.com>
    Reviewed-by: Sumit Bose <sbose@redhat.com>