lscpu: fix panic when physical_package_id is -1

[mmclinton]

Fixes #495

lscpu panics with ParseIntError { kind: InvalidDigit } at sysfs.rs:57 on machines where /sys/devices/system/cpu/cpuN/topology/physical_package_id contains -1.

-1 is the kernel's documented fallback for physical_package_id when the architecture does not define the corresponding topology macro (observed on ppc64 in #495): https://www.kernel.org/doc/html/latest/admin-guide/cputopology.html

The code parsed the value as usize, so the fallback value failed to parse and the unwrap() panicked. This PR parses it as i64 instead. pkg_id is only used for a distinct-count in socket_count(), so -1 needs no special-casing: all-unknown ids collapse into a single socket bucket, which matches what util-linux lscpu is observed to report (Socket(s): 1) under the same conditions.

core_id is left as usize: the kernel's documented fallback for it is 0, not -1.

Testing

• Reproduced the reported panic by bind-mounting a file containing -1 over every physical_package_id in a mount namespace (unshare -Urm); after the fix the same setup exits 0 and reports Socket(s): 1, the same topology values util-linux lscpu prints there.
• Added a unit test covering socket_count()/core_count() with unknown (-1) package ids.
• Output on a machine with real package ids is unchanged.