#2722 PE timestamps make no sense in reproducible builds

[Alex Alabuzhev]

1. Have Windows 10 or newer.
2. Run 7z.exe l c:\windows\system32\kernel32.dll
3. Inspect the list

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2084-07-22 02:02:17 .....       524955       525312  .text
2084-07-22 02:02:17 .....       213774       214016  .rdata
2084-07-22 02:02:17 .....         1536         1536  .data
2084-07-22 02:02:17 .....        22236        22528  .pdata
2084-07-22 02:02:17 .....          104          512  .didat
                    .....         1656         1656  .rsrc\version.txt
                    .....          200          200  .rsrc\MUI\1
2084-07-22 02:02:17 .....         1172         1536  .reloc
2084-07-22 02:02:17 .....        34000        34000  CERTIFICATE
------------------- ----- ------------ ------------  ------------------------
2084-07-22 02:02:17             799633       801296  9 files

1. Notice that timestamps make no sense.
2. Same happens when using API and external clients of 7z.dll.

The root cause is that now PE timestamp sometimes has an entirely different meaning.

The Old New Thing article:
https://devblogs.microsoft.com/oldnewthing/20180103-00/?p=97705/

Documentation:
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#debug-type

The presence of an entry of type IMAGE_DEBUG_TYPE_REPRO indicates the PE file is built in a way to achieve determinism or reproducibility. If the input does not change, the output PE file is guaranteed to be bit-for-bit identical no matter when or where the PE is produced. Various date/time stamp fields in the PE file are filled with part or all the bits from a calculated hash value that uses PE file content as input, and therefore no longer represent the actual date and time when a PE file or related specific data within the PE is produced.

In other words, PeHandler.cpp should probably inspect the Type field of the debug directory entry, and, if set to IMAGE_DEBUG_TYPE_REPRO, either report kpidMTime, kpidCTime etc. properties as absent, or use file timestamp values for them, or do something else sensible rather than parse hashes as timestamps.

[Igor Pavlov]

I'll fix it.
Thanks!