Separates the logic of the watcher from the subscriber for two reasons:\n - First, we should abstract the subscriber as an entity that handles the underlaying bitcoin client and feeds parsed data to pipeline that the watcher can read from. That way we can have different types of subscriber (not necessarily based on zmq).\n - Secondly, the responder will need to also receive data from the subscriber (as a different instance) to keep track of the state of the response.
The watcher can get appointments (containing only the locator) and find them in new generated blocks. Decryption and communication with the responder is still missing
Improves the dummy watcher logic. Sets a proper structure. Watcher can now check for potential matches and handle multiple appointments with the same locator (hash collisions).
Merges tx_watcher and zmq_subscriber into a single file: watcher. Watcher will handle all the watching process and container two inner classes, the watcher and the ZMQHandler
