Use a singleton threadpool for kex message handler flushing

[FliegenKLATSCH]

fixes #458
Threads will expire after 60 seconds.

[tomaswolf]

While the task submitted in flushQueue() quits when a new KEX has started while flushing or when the session has been closed while flushing, I wonder if we now need something to prevent a second task being submitted by the same session before the first one has ended.

[garydgregory]

Should the threads be daemon threads?

[FliegenKLATSCH]

While the task submitted in flushQueue() quits when a new KEX has started while flushing or when the session has been closed while flushing, I wonder if we now need something to prevent a second task being submitted by the same session before the first one has ended.

Good point, I'd tend to say no because of the locking in the loop.

Should the threads be daemon threads?

Actually not really, but the same is probably true for other usages as well :/ Wondering if this would be a real world issue, since implementations would anyway wait for a response. Could rather be an issue on the server side.
Should we make it configurable? I am wondering if someone knows some good framework around thread pools to be used?
Just to make it clear: They will become daemon threads with the proposed change. I think there are reasons for and against it. If we want to prevent loosing some packets on a shutdown, we could wait for the threads to be finished in a shutdown hook.