Fix a Y2038 bug by replacing Int32x32To64 with regular multiplication (#2471)

`Int32x32To64` macro internally truncates the arguments to int32, while
`time_t` is 64-bit on most/all modern platforms. Therefore, usage of
this macro creates a Year 2038 bug.

I detailed this issue a while ago in a writeup, and spotted the same
issue in this repository when updating the list of affected
repositories:
<https://cookieplmonster.github.io/2022/02/17/year-2038-problem/>

A few more notes:
1. I changed all uses of `Int32x32To64` en masse, even though at least
one of them was technically OK and used with int32 parameters only. IMO
better safe than sorry.
2. This is untested, but it's a small enough change that I hope the CI
success is a good enough indicator.

(cherry picked from commit 14b8803c40)

cpio/cpio_windows.c

@@ -171,7 +171,7 @@ cpio_CreateFile(const char *path, DWORD dwDesiredAccess, DWORD dwShareMode,
 	return (handle);
 }
 
-#define WINTIME(sec, usec)	((Int32x32To64(sec, 10000000) + EPOC_TIME) + (usec * 10))
+#define WINTIME(sec, usec)	(((sec * 10000000LL) + EPOC_TIME) + (usec * 10))
 static int
 __hutimes(HANDLE handle, const struct __timeval *times)
 {

libarchive/archive_write_disk_windows.c

@@ -2606,7 +2606,7 @@ set_times(struct archive_write_disk *a,
     time_t ctime_sec, long ctime_nanos)
 {
 #define EPOC_TIME ARCHIVE_LITERAL_ULL(116444736000000000)
-#define WINTIME(sec, nsec) ((Int32x32To64(sec, 10000000) + EPOC_TIME)\
+#define WINTIME(sec, nsec) (((sec * 10000000LL) + EPOC_TIME)\
 	 + ((nsec)/100))
 
 	HANDLE hw = 0;

test_utils/test_main.c

@@ -2108,7 +2108,7 @@ assertion_utimes(const char *file, int line, const char *pathname,
 	int r;
 
 #if defined(_WIN32) && !defined(__CYGWIN__)
-#define WINTIME(sec, nsec) ((Int32x32To64(sec, 10000000) + EPOC_TIME)\
+#define WINTIME(sec, nsec) (((sec * 10000000LL) + EPOC_TIME)\
 	 + (((nsec)/1000)*10))
 	HANDLE h;
 	ULARGE_INTEGER wintm;