Declare the ProcThreadAttributeList APIs with pointer-width sizes (#117)

* Declare the ProcThreadAttributeList APIs with pointer-width sizes

#116 added declarations for InitializeProcThreadAttributeList and
UpdateProcThreadAttribute using subprocess_size_t where the SDK has SIZE_T,
PSIZE_T and DWORD_PTR. Those are ULONG_PTR, which is unsigned long on Win32
while subprocess_size_t is unsigned int there. Same width, distinct types, so
the redeclaration itself is rejected before any call is reached:

    subprocess.h(461,1): error C2733: 'InitializeProcThreadAttributeList':
        you cannot overload a function with 'extern "C"' linkage
    subprocess.h(1157,3): error C2664: cannot convert argument 4 from
        'subprocess_size_t *' to 'PSIZE_T'

Win64 is unaffected because ULONG_PTR and subprocess_size_t agree there, which
is why cmake.yml does not see it — it builds Windows x64 only.

Added subprocess_ulongptr_t and used it for those parameters and for
attribute_list_size. It sits outside the _MSC_VER < 1920 split, or newer MSVC
would keep taking size_t from <inttypes.h> and stay broken.

Reproduced with MSVC 19.44 and SDK 10.0.26100 before the change and verified
after: -A Win32 goes from four errors to a clean build with both test binaries
passing, -A x64 still passes, and Linux glibc is unchanged at 442/442 in both
implementations.

* Derive the pointer-width type instead of naming __int64 again

clang-cl rejects the new typedef under -Weverything:

    subprocess.h(348,18): error : extension used
        [-Werror,-Wlanguage-extension-token]

The identical typedef a few lines above does not trip it because it sits
behind _MSC_VER < 1920, which clang-cl never compiles. Mine does not.

On _WIN64 subprocess_size_t is already 64 bits wide and so matches ULONG_PTR,
so reusing it avoids naming the extension token at all. Win32 keeps
unsigned long, which is what SIZE_T is there.

MSVC 19.44 builds and passes on both -A Win32 and -A x64. clang-cl is not
installed here, which is why CI found this and the local run did not.