Rewrite in favor of ProtocolV2

The current protocol (v1) is insecure. To fix this, we'll introduce ProtocolV2.

The first change is that the server will now be sending a challenge with it's version payload sent initially to the client. The payload will look like so:
```
VOTIFIER 2.0 4blpmp48dh27thonajemi2qte2
```
ProtocolV2 uses JSON for messages. An example message is below:
```
{
	"service": "MinecraftServerList", // name of the service
	"signature": "YmFzZTY0ZW5jb2RlZHNpZ25hdHVyZQ==", // sha256withrsa signature
	"payload": "{
		\"host\": \"myservername.com\", // the host that we are connecting to (useful for vhosting)
		\"username\": \"etc\", // username of the originating voter
		\"address\": \"123.123.123.123\", // ip address of the originating voter
		\"challenge\": \"4blpmp48dh27thonajemi2qte2\", // random string initially sent by the server
		\"timestamp\": 1396257969 // unix time
	}"
}
```

Every voting website will have an RSA key pair. (php generator @ https://gist.github.com/coelho/9887580) It will allow users to add it to their config.yml as such:
```
host: 0.0.0.0
port: 8192
debug: false
listener_folder: plugins/Votifier/listeners
enable_old_protocol: true
websites:
  test: https://example.com/votifier/public.key
```
This RSA key pair will be used to perform SHA256withRSA signature signing on the payload. The Votifier server can then validate the signature against the payload and public key (retrieved from the website in the config.yml with the matching service name).

The server is responsible for sending a challenge at the beginning of the connection that the client must send back in the signed payload. This resolves issues with replay attacks.

If the public key is not loaded over SSL, there will be a warning in console stating that it is insecure.
Usage of the old protocol after this has become the standard will result in a warning in console that it is insecure.

Pros:
1) This is secure.
2) We provide compatibility towards V1 and V2 at the same time (with the option to disable V1 for security reasons).
3) This is much easier for server owners to setup in the long run.
4) This protocol is so much more beautiful (I mean JSON oh my god).
5) We no longer block while serving clients on the acceptor.

Cons:
1) We can't do this on our own. Every server list owner must see the importance in this and implement it. We can help them by creating some useful libraries for Ruby and PHP.
2) The new setup process may be confusing at first for server owners (because it is different).

Known Issues:
1) If "Server" trusts "Voting Website", and "Attacker" submits "Server"'s Votifier to "Voting Website", he can submit votes to that banner that were not intended for "Server". The solution to this issue is to implement unique IDs, where the "Voting Website" will send a unique ID to the client that the client must cache and forever keep. If he ever receives a different unique ID, he shall reject the request.

Thanks @blakeman8192 for helping me out with this :+1: 
Use some kind of thread pool here or at least limit the number of simultaneously running threads.