Possible fix for XP SP0 System process exploit crash

Exploitation of the System process on Windows XP SP0 resulted in crashes
when metepreter was enumerating network interfaces. It appears that the
System process isn't able to read from the address that contains prefixes
(stored in pPrefix in interfaces.c). In other cases, such as exploitation
of svchost.exe or via an msfpayload-generated exe, there was no such
crash. This is not an issue on later versions of Windows.

This crash happens in the current "production" version of Meterpreter that
was deployed with MSF v4.7.

The MS08-067 exploit targets the System process, and hence crashes.
The MS03-26 exploit targets svchost, and hence does not crash.

Checking the protection of the memory in each of those cases showed that
the MEM_COMMIT was set when not the System process, and was MEM_RESERVED
when it was. Sample runs can be seen here: http://pastebin.com/2WHqJ90A

This commit is an attempt to avoid this crash down the track, and it just
does a simple check to see if querying the area of memory for the current
process shows a state of MEM_COMMIT. If so, it carries on as per normal,
if not it uses the other legacy code path to traverse the network
interfaces.

With this "fix" in place I have not seen a crash at all on Windows XP,
Windows 7, Windows 8 and Windows 2012.
Fix issue with kitrap0d crashing meterpreter

Calling getsystem or getsystem -t 4 was resulting in crashes due to
an incorrect usage of sizes in a call to _sprintf_s in the kitrap0d
code. This might have come about as a result of a move to the new
compiler which is C++11.

This code forces the size check to be correct and results in the
exploit functioning correctly on all platforms.
Updated fix to work properly with _snprintf_s

* Modified first and second parameters to use `dwOutputLength` which
  is given to the function as an indicator of buffer size in bytes
  anyway.
* Check the return value of the function call to see if the result
  was a truncation, and if so, break from the current loop.

Realistically, truncation will not happen because the default windows
installation location folder name is very short.

Thanks @jvazquez-r7 for prodding me to validate this.
Last code tidy for the kitrap0d fix

Tidies up the API to be more intuitive, including conversion of the
first parameter to a char pointer (removing MAX_PATH) and renaming
the second parameter to be more indicative of what it means.

Thanks to @jvazquez-r7 for the great discussion!
Land #23, @OJ's fix for kitrap0d
Better fix for the XP SP0 problem

Thanks to @jvazquez-r7 doing some investigation we have a better solution
to this crash. This commit implements this fix and removes the need to
check the status of the memory that's being read.
Land #21, @OJ's fix for PIP_ADAPTER_PREFIX Length check