kdirwatch: don't leave relative entries dangling
another supremely awkward bug revealed by forcing good refcounting... previously when the user had called `addFile()` with a relative path we'd happily create an `Entry` for it but never remove it. this was because `entry()` would not return a matching entry when the path was relative. this then left relative entries dangle with potentially invalid `client` members. specifically in the call chain `::~KDirWatch -> ::removeEntries -> ::removeEntry -> ::entry` that was of considerable problem as the KDirWatch instances cleanup request was effectively ignored. eventually when cleanup of the private happened we'd then tap into invalid memory when trying to clean up the client. the presented test case demonstrates this and the fix is simply not checking for relativity when the rest of the class doesn't either