Fix x64 warnings

[malxau]

This is mainly casts to prevent x64 compiler warnings. I looked at each case manually, mainly just preserving existing behavior. Although it touches quite a bit, there's really a handful of patterns:

1. It looks like the code was bulk converted to use GetWindowLongPtr rather than GetWindowLong. That implies truncating a 64 bit return value. GetWindowLongPtr is needed for pointers or handles, but isn't needed for 32 bit values. Nonetheless this change preserves them and casts the result, because I'll bet this conversion happened due to some other overzealous warning or analysis suggesting GetWindowLong isn't safe in 64 bit code.
2. There is arithmetic on 32 bit control IDs to map to extensions. We shouldn't have more than 4 billion extensions.
3. SetStatusText can take either a string or a resource ID. This leads to upcasting a 32 bit integer into a 64 bit pointer. An additional 64 bit integer intermediate is used here. The usage appears safe.
4. SendMessage and friends return a pointer sized return, but the meaning depends on the message type. For many messages, truncation is appropriate.
5. strlen and friends return size_t. (Aside: this has always annoyed me; just because a system has a 64 bit address space, doesn't mean any sane code wants to walk through 4Gb of memory looking for zero.) In many cases we "know" strings can't be this long so the result can be casted. Similarly, pointer arithmetic can be used to determine the length between two elements in a string, which we "know" should be less than 4Gb.
6. The current code assumes we can't have more than 2^31 items in a list, which seems like something we're unlikely to need any time soon.
7. ShellExecute and friends return a handle which can be 64 bit. This code has two places where it translates success to zero, so the post-translated values cannot be 64 bit.
8. There's code for PenWindows which I'm fairly sure never worked in 32 bit. In 16 bit, GetSystemMetrics can return a handle to the DLL, since the DLL once loaded is in the address space of every process. In 32 bit, something has to actually map it, so GetSystemMetrics was documented to return zero/nonzero rather than the DLL base. Also, RegisterPenApp was the 1.0 function which was replaced in 2.0 by SetPenAppFlags, and according to the 32 bit penwin.h, RegisterPenApp is not available as 32 bit. If this ever did work, I'm curious about the NT 3.x pen enabled device it ran on - the intersection between those two seems minuscule at best.

[schinagl]

I sneaked through all changes and they seem fine to me. Since I can't approve on the github GUI, I do it with this comment