Investigate reconnection logic

[xforever1313]

This is spun off of #23. We should figure out how to deal with reconnection. What if the parsing queue is very full, and we don't get a PONG back from the server before it has a chance to tell the watchdog? We'll reconnect for no good reason.

Per #23:

However, if several events are hanging for whatever reason, and we send a ping and wait for a pong, no amount of interrupts are going to save us before we time out. What we should do is when we reconnect via the watchdog thread, we should add that to the parsing queue. Then, once the parsing queue catches up, it will reconnect. When we reconnect, we'll restart the connection watchdog.

[xforever1313]

Different approach:

Let's not handle pings and pongs on the string parsing queue. We don't want to connect/reconnect while the string parsing queue is busy. Instead, we should handle Pings and Pongs directly on the ReaderThread. This also means a user of Chaskis.Core doesn't have to add PingHandler and PongHandler to the list of handlers. This means PingHandler and PongHandler become internal instead of public.

This also means if we have multiple connections, we don't have to worry about juggling pings and pongs; everything is self-contained.

[xforever1313]

I'm going to close this issue. I think we know what the root-cause of all of this is, and we have a fix. We don't have any regression tests for this, but I'm not sure if its worth the trouble of adding one. Honestly, I wouldn't even know where to begin, there's a lot to add for something that can be clearly seen during code inspection.