Corrected how copying an Affix object works.

The previous (e.g. 810f8b962f471e3a12f6219043f6a5957826db06)
description got this right: You create a new Affix object of
the same class as this current Affix you would like to copy,
give it the same parameters the current Affix got on instantiation,
copy any additional state it has (besides `self.affix_context`),
and return it.
Sometimes, you will deliberately suppress state information ---
see the NamingAndResolverAffix (update to be committed) for an
example.
More fixes from integration testing with nodemanager.

* canilisten.r2py: More verbose error message.
* MakeMeHearAffix: Remember the `next_affix` from instantiation time as
  `original_next_affix`. It is used to restore the original stack if
  a TCPServerSocketInvalidError is encountered. This is triggered by
  tcpserversocket_getconnection checking for and reacting on that error.
  Using the same approach in other places where I previously `pop()`'ed
  from the stack.
* NamingAndResolverAffix: Removed unused `REDO_INTERVAL`; corrected
  `copy()` to return a new instance of my class rather than myself;
  figured out how to make copies without them spawning new advertise
  / IP check threads: Don't instantiate them with a stack ID attribute!
* TCPRelayAffix: Added `sockettimeout.SocketTimeoutError` to an except
  so we don't raise exceptions that are not in the Repy API; also
  raise the new `TCPServerSocketInvalidError` when a listening socket
  becomes stale.
Add interactive test scripts for debugging.

Run these scripts, then fiddle with your network interfaces
(up, down, change address, ....) and see how the MakeMeHearAffix
and NamingAndResolverAffix react.