fix deadlock from rfbReleaseExtensionIterator(), fix no libz/libjpeg builds, disable tightvnc-filetransfer if no libpthread, add --without-pthread option, rm // comments, set NAME_MAX if not defined, x11vnc: throttle load if fb update requests not taking place.

If the client asked for an encoding, and no enabled extension handled it,
LibVNCServer would walk through all extensions, and if they promised to handle
the encoding, execute the extension's newClient() if it was not NULL.

However, if newClient is not NULL, it will be called when a client connects,
and if it returns TRUE, the extension will be enabled. Since all the state of
the extension should be in the client data, there is no good reason why
newClient should return FALSE the first time (thus not enabling the extension),
but TRUE when called just before calling enablePseudoEncoding().

So in effect, the extension got enabled all the time, even if that was not
necessary.

The resolution is to pass a void** to enablePseudoEncoding. This has the
further advantage that enablePseudoEncoding can remalloc() or free() the
data without problems. Though keep in mind that if enablePseudoEncoding()
is called on a not-yet-enabled extension, the passed data points to NULL.

so that more than one data structure can be attached, and add an example
to speak the client part of the back channel.

Thank you very much, Rohit!

the processCustomClientMessage() method.

I eventually saw the light and went with Rohit´s original approach.