Add an NTP fuzzer

I wrote this to help me understand NTP a little better as well as try to find NTP protocol anomalies that might be vulnerabilities.

Sample output:

```
[*] cisco2620.vuln:123 fuzzing version and mode combinations
[*] cisco2620.vuln:123 -- Received 48-byte version 1 mode 4 reply to 48-byte version 1 mode 3 packet
[+] cisco2620.vuln:123 -- Received 8-byte version 3 mode 7 reply to 48-byte version 1 mode 7 packet: version mismatch
....
[*] cisco2620.vuln:123 -- Received 48-byte version 2 mode 2 reply to 48-byte version 2 mode 1 packet

[+] cisco2620.vuln:123 -- Received 8-byte version 3 mode 7 reply to 48-byte version 4 mode 7 packet: version mismatch
[*] cisco2620.vuln:123 -- Received 48-byte version 5 mode 4 reply to 48-byte version 5 mode 3 packet
[+] cisco2620.vuln:123 -- Received 8-byte version 3 mode 7 reply to 48-byte version 5 mode 7 packet: version mismatch
[*] cisco2620.vuln:123 -- Received 48-byte version 6 mode 2 reply to 48-byte version 6 mode 1 packet
[*] cisco2620.vuln:123 -- Received 48-byte version 6 mode 4 reply to 48-byte version 6 mode 3 packet
[+] cisco2620.vuln:123 -- Received 8-byte version 3 mode 7 reply to 48-byte version 6 mode 7 packet: version mismatch
[*] cisco2620.vuln:123 -- Received 48-byte version 7 mode 2 reply to 48-byte version 7 mode 1 packet
[*] cisco2620.vuln:123 -- Received 48-byte version 7 mode 4 reply to 48-byte version 7 mode 3 packet
[+] cisco2620.vuln:123 -- Received 8-byte version 3 mode 7 reply to 48-byte version 7 mode 7 packet: version mismatch
[*] cisco2620.vuln:123 fuzzing short version and mode combinations
[+] cisco2620.vuln:123 -- Received 8-byte version 3 mode 7 reply to 4-byte short version 1 mode 7 packet: large response,version mismatch
...
[*] cisco2620.vuln:123 fuzzing short messages
[+] cisco2620.vuln:123 -- Received 8-byte version 3 mode 7 reply to Short 0-byte random packet: large response,version mismatch
[+] cisco2620.vuln:123 -- Received 8-byte version 3 mode 7 reply to Short 2-byte random packet: large response,version mismatch
[*] cisco2620.vuln:123 fuzzing random messages
[+] cisco2620.vuln:123 -- Received 8-byte version 3 mode 7 reply to random 48-byte packet: version mismatch
[*] cisco2620.vuln:123 fuzzing control messages (mode 6)
[*] cisco2620.vuln:123 -- Received 12-byte version 1 mode 6 reply to 12-byte version 1 mode 6 op 0 packet
[+] cisco2620.vuln:123 -- Received 16-byte version 1 mode 6 reply to 12-byte version 1 mode 6 op 1 packet: large response
[+] cisco2620.vuln:123 -- Received 228-byte version 1 mode 6 reply to 12-byte version 1 mode 6 op 2 packet: large response
[*] cisco2620.vuln:123 -- Received 12-byte version 1 mode 6 reply to 12-byte version 1 mode 6 op 3 packet
```

Those large responses are effectively the monlist/CVE-2013-5211 being discovered using fuzzing. The bulk of the other findings are either minimal DoS conditions or potential protocol violations exhibited by the NTP endpoint in question.
So, when I write fuzzers, I like to cover two types of data, long and tall data.

Long data is how it sounds, you send a lot of bytes, incrementally (50, 100, 500, 1000, 5000, etc). The bytes can be random up with a length up to a ridiculous amount relative to the protocol.

Tall data is fuzzing values in the data, not the amount of data. So incrementing the bytes from 0x00 to 0xff, maybe 4 at a time (ints woot). This tends to weed out signed integer problems for the most part, can lead to finding stack overflows too.

Hope that makes sense. This is a cool module. :)