Remove NETMASK option from Capture, fixing functionality on networks with a netmask other than /24

As explained in #4306, the ```NETMASK``` option has a suboptimal default value that causes many Capture modules to function improperly on some networks with a netmask larger (and perhaps smaller) than ```/24```.  This simply removes this option entirely and calculates the correct netmask by getting it directly from Pcap.

To see this bug in action, and similarly to confirm it is fixed, you need two hosts (A and B) in the same broadcast domain with default gateway G (which is not A or B) and CIDR netmask N.  They have MACs MAC-A, MAC-B and MAC-G.  They do *not* need to be running any particular services or be configured in any particular way -- simply responding to ARP requests is sufficient.

- [ ] Pick a module that utilizes ```capture_sendto```.  For this example, I'm using ```exploit/multi/ids/snort_dce_rpc```
- [ ] On ```A```, run ```tcpdump``` with a filter that will only capture traffic from the module above -- ```tcpdump -eni eth0 '(ether host MAC-A and arp) or ((ether host MAC-B or ether host MAC-G)' and port 139)'``` (this will show any ARPs sent by A as well as any port 139 traffic supposedly sent by the module, however you should tune this if you would normally have port 139 traffic flowing between A and B or G)
- [ ] On ```B```, run the same ```tcpdump``` 
- [ ] From ```A```, set the appropriate module options (in this case, simply ```RHOST```) and run the module.  Do *not* set ```NETMASK```
- [ ] Notice that both A and B's tcpdumps show several ARPs and that the destination MAC of the port 139 traffic is MAC-B.
- [ ] Set ```NETMASK``` to something  more restrictive than ```N``` (if it was originally 24, try 31).  Stop and restart the tcpdumps.  Re-run the module.
- [ ] Notice that the destination MAC of A's 139 traffic is MAC-G.  Depending on how G is configured, you may see this traffic forwarded on to B.  
 
By doing this you are simulating what is happening when the default ```NETMASK``` of 24 is smaller than the actual netmask in use (mine was a /20).

To confirm that this introduces no ill side effects and that the correct netmask is used regardless of what is actually configured (rather than just assuming /24), you'll need to recreate the previously described setup but with two different netmasks:

- [ ] Configure A, B and G with a netmask of 24.
- [ ] Pick a module that utilizes ```capture_sendto```.  For this example, I'm using ```exploit/multi/ids/snort_dce_rpc```
- [ ] On ```A```, run ```tcpdump``` with a filter that will only capture traffic from the module above -- ```tcpdump -eni eth0 '(ether host MAC-A and arp) or ((ether host MAC-B or ether host MAC-G)' and port 139)'``` (this will show any ARPs sent by A as well as any port 139 traffic supposedly sent by the module, however you should tune this if you would normally have port 139 traffic flowing between A and B or G)
- [ ] On ```B```, run the same ```tcpdump``` 
- [ ] From ```A```, set the appropriate module options (in this case, simply ```RHOST```) and run the module.
- [ ] Notice that both A and B's tcpdumps show several ARPs and that the destination MAC of the port 139 traffic is MAC-B.
- [ ] Reconfigure A, B and G with a netmask other than 24 that, when applied to the network in question, includes A, B and G.  Picking something less restrictive is easiest, like 20.  Redo steps 2-6.