Update the dynamic libnotify check for the newer soname
    
    See bug https://bugzilla.redhat.com/show_bug.cgi?id=693362
    
    The xchat code currently does:
    
       nn_mod = g_module_open ("libnotify", G_MODULE_BIND_LAZY);
    
    which looks for "libnotify" which fails, then "libnotify.so" which fails, then
    "libnotify.la" which fails.
    
    The above then looks for "/usr/lib64/libnotify.so".
    
    On developer systems with libnotify-devel installed, this file exists, so it
    happily loads libnotify support for us.  However, on user systems, it does not
    exist which leads to that g_module_open call outright failing.  This explains
    why it appeared to be working for me and presumably Owen too, but not for
    the reporter.
    
    Then, the xchat code tries to load the (wrong) versioned module.  Naturally,
    that fails, too. At that point, it then falls back to use notify-send.
    
    I'm not sure the motivations for dynamically loading the library instead of
    linking directly, but I think a correct minimalistic fix is to do:
    
    -     nn_mod = g_module_open ("libnotify", G_MODULE_BIND_LAZY);
    +     nn_mod = g_module_open ("libnotify.so.4", G_MODULE_BIND_LAZY);
    
    This adds the newest versioned library at the top of the check, and still keeps
    the old versioned library.  However, it also removes the devel only library
    from the list which reduces the chances that developers will be blind to this
    issue in the future.  There's no real reason to look there anyway since users
    just won't have that installed.
    
    But this is all really just a hack.  The proper fix should be simply to link
    directly against libnotify.  notify-send is part of libnotify anyway so it is
    entirely reasonable to expect systems that have notify-send installed to also
    have libnotify itself installed.