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.

CCBUG: 472862