Move non-windows stuff to pcap_unix; Convert windows to implicit linking

[notti]

This add support for npcap on windows.
Windows now supports both npcap and winpcap at the same time. If both
winpcap and npcap are installed at the same time, npcap is preferred.
Building on windows now doesn't need neither cgo nor npcap/winpcap sdks.

The way this works is that all the non-windows stuff is now in pcap_unix.go, while all the windows stuff is in pcap_windows.go. Those two files provide a go-only internal api to pcap.go which to the outside looks the same as before (except for the small change mentioned below).
The new windows code now doesn't use cgo (this is a pain to use on windows) and uses implicit linking (I couldn't get delay loading to work with cgo). => neither cgo nor npcap/winpcap sdk is needed. syscall.Syscall is used for all the calls and the wpcap.dll is loaded in init(). Since both npcap and winpcap provide a wpcap.dll with libpcap api - no distinctions between the two are necessary (except for the not supported api functions in older libpcap versions as before). The only place where npcap is used, is an additional ddlload path that is added before loading the actual wpcap.dll.

Gains: Now the pcap tests work on windows (only with npcap - with winpcap some of the tests fail due to outdatet libpcap (e.g. no pcapng support, ...))

API of pcap.go is the same as before except for one small change:

gopacket/pcap/pcap.go

Line 795 in a3c4a85

func DatalinkNameToVal(name string) C.int {

The function signature of this one seems to be wrong and slipped through the cracks (all related functions (e.g., DatalinkValToName) accept int as value and not C.int
Additionally, I think C.*-types should never be exposed and this seems like a mistake.
If this is bad since it might break something, I can change it back.

Ad performance: the new version has an additional function call in getNextBufPtrLocked since pcapNextPacketEx can't be inlined. But the new ReadPacketData is faster since it doesn't use C.GoBytes any longer (which is a call into C code! - I think this function is supposed to be used from within C and not go...)
Testing with the gopacket_benchmark was inconclusive.

Ad windows: Right now there is no support to select winpcap if both npcap and winpcap are installed... I don't know if there would be a good way to do that.

[negbie]

Finally I can remove this bookmark ;)
https://stackoverflow.com/questions/38047858/compile-gopacket-on-windows-64bit

Thank you very much @notti !!

[notti]

Happy to help.
If you encounter issues, or it's working for you, please add a comment.
I could only test on windows 7 64 bit (with both winpcap and npcap, tests that are included in gopacket, example programs, and some some smoke tests) - as well as linux.

[gconnell]

notti, this is truly phenomenal work. Thanks a ton for working on this!

[gconnell]

Looks great! Merging in now...