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