storage: Fix existing parent check for vHBA creation
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1472277
    
    Commit id '106930aaa' altered the order of checking for an existing
    vHBA (e.g something created via nodedev-create functionality outside
    of the storage pool logic) which inadvertantly broke the code to
    decide whether to alter/force the fchost->managed field to be 'yes'
    because the storage pool will be managing the created vHBA in order
    to ensure when the storage pool is destroyed that the vHBA is also
    destroyed.
    
    This patch moves the check (and checkParent helper) for an existing
    vHBA back into the createVport in storage_backend_scsi. It also
    adjusts the checkParent logic to more closely follow the intentions
    prior to commit id '79ab0935'. The changes made by commit id '08c0ea16f'
    are only necessary to run the virStoragePoolFCRefreshThread when
    a vHBA was really created because there's a timing lag such that
    the refreshPool call made after a startPool from storagePoolCreate*
    wouldn't necessarily find LUNs, but the thread would. For an already
    existing vHBA, using the thread is unnecessary since the vHBA already
    exists and the lag to configure the LUNs wouldn't exist.
    
    Signed-off-by: John Ferlan <jferlan@redhat.com>