winfile 1.1.0

This release closes the gap named at the bottom of the 1.0.0 notes: ELF binaries
were reported only by their broad class. They are now described the way GNU
file describes them.

1.0.0:  ELF 64-bit LSB shared object

1.1.0:  ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
        interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc6a4214…,
        for GNU/Linux 3.2.0, stripped

Core dumps report where they came from:

ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from '/usr/bin/crasher',
real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000,
execfn: '/usr/bin/crasher', platform: 'x86_64'

What is reported

Object type, machine, ELF version and OS/ABI; linkage (dynamically,
statically or static-pie linked); the PT_INTERP interpreter path; GNU and
Go build IDs; the .note.ABI-tag target OS and version; presence of
.debug_info; stripped state; and, for core dumps, the dumping process with its
real and effective uid and gid, execfn and platform.

Two of these are inferred rather than read from a field, matching what GNU file
does. An ET_DYN image is a pie executable when its .dynamic section
carries DT_FLAGS_1 with DF_1_PIE, and a shared library otherwise. It is
static-pie linked when it has no interpreter and no DT_NEEDED entries, so
there is nothing to bind at run time.

MIME output follows suit — -i and --mime-type now distinguish
application/x-executable, x-pie-executable, x-sharedlib, x-object and
x-coredump instead of reporting a single type for every ELF file.
--extension reports ???, as GNU file does for ELF.

Verified against the original

Differentially tested against GNU file 5.41 over a 1348-file corpus — /bin,
shared libraries, relocatable objects, static and PIE executables, Go binaries
and a real core dump — with no differences in the description, --mime-type,
-i or --extension.

Known differences are listed in the README. The main one: only x86-64, i386, ARM,
AArch64, RISC-V and 64-bit PowerPC are named. The e_machine table has a long
tail, and winfile leaves an unrecognised machine unnamed rather than guessing at
it.

Binaries

Asset	Platform
winfile_windows_amd64.exe	Windows, x86-64
winfile_windows_arm64.exe	Windows, ARM64
winfile_linux_amd64	Linux, x86-64
winfile_linux_arm64	Linux, ARM64

Each is self-contained: put one on your PATH and run it, nothing to extract or
install. On Linux, chmod +x it first.

The binary takes its name from argv[0], so renaming it renames the tool in its
own messages — copy it as winfile.exe, or as file if you would rather it
answered to that.