kdirwatch: don't crash after moving threads
if a user moves a public watch instance across threads we used to have a d but now local data (thereby not running the dtor) and so eventually the private watch in the old thread would try to emit data into a since deleted public watch in the new thread
to prevent this problem we'll "brick" the watch upon moving threads. specifically we'll fully unregister it with the old private and create/apply a new private in the new thread.
since we currently have no way to reliably copy Entry as part of this we cannot really replicate the correct watches on the new thread. definitely something that could be made to work in the future though. in the meantime critically log that moving threads does not do what you expect it to do when used with kdirwatch.