Eliminate crash in mac_prefix_init() on platforms with 32-bit long

[chrstphrchvz]

The type of (pfx & 0xfffffffffL) is uint64_t, which is unsigned long long on platforms with 32-bit long (as well as some platforms with 64-bit long). But %0*lX in the format string expects type unsigned long, which the compiler already warns about:

MACLookup.cc: In function 'void mac_prefix_init()':
MACLookup.cc:161:29: warning: format '%lX' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=]
  161 |       error("MAC prefix %0*lX is duplicated in %s; ignoring duplicates.", (int)(pfx >> 36), pfx & 0xfffffffffL, filename);
      |                         ~~~~^                                                               ~~~~~~~~~~~~~~~~~~
      |                             |                                                                   |
      |                             long unsigned int                                                   long long unsigned int

nmap-mac-prefixes currently does not contain any duplicate entries. But if it did contain a duplicate entry, and nmap is run with debug level 2 or higher, then a crash will occur on 32-bit systems due to part of (pfx & 0xfffffffffL) being mistaken for the address of the filename buffer; on little endian systems, the invalid address is either the leading digit of a 36-bit MAC prefix, otherwise 0.

Example command which triggers this crash, after editing nmap-mac-prefixes to contain a duplicate entry:

sudo nmap -sU --script nbstat.nse -p137 -d2 192.168.0.1

This crash can be eliminated by using the correct format specifier for uint64_t. I have tested this approach on IA-32 Linux as a patch for nmap 7.94, which is currently the only release affected by this issue.