lscpu: Skip aarch64 decode path for rest of the architectures

lscpu: Skip aarch64 decode path for rest of the architectures

lscpu behaves differently when run sudo vs non-sudo on AMD architectures.

On sudo runs, it adds a BIOS model name and BIOS CPU family which it
does not add for the latter. However since this parsing from the DMI is
primarily catered to aarch64, for AMD platform the BIOS model name is
printed out as follows "AMD XXX Processor *Unknown* CPU @ X.XGHz" due
to the part number is not populated on the platform.

The issue boils down to an unconditional call to arm_decode() which
attempts to read the DMI path and populate the processor information
such as processor version and part number which is set to Unknown on AMD
CPUs.

81d6de9 (lscpu: remove the old code) changed the DMI path from
/sys/firmware/dmi/entries/4-0/raw (non-existent) to
/sys/firmware/dmi/tables/dmi (existent) which has brought this latent
issue to light as DMI was starting to be parsed incorrectly.

Therefore, do not perform aarch64 parsing for other architectures.

Before
------
$ lscpu
Vendor ID:                AuthenticAMD
  Model name:             AMD EPYC XXXX X-Core Processor
    CPU family:           26

$ sudo lscpu
Vendor ID:                AuthenticAMD
  BIOS Vendor ID:         Advanced Micro Devices, Inc.
  Model name:             AMD EPYC XXXX X-Core Processor
    BIOS Model name:      AMD EPYC XXXX X-Core Processor	Unknown CPU @ X.XGHz
    BIOS CPU family:      107
    CPU family:           26

After
-----
$ lscpu
Vendor ID:                AuthenticAMD
  Model name:             AMD EPYC XXXX X-Core Processor
    CPU family:           26

$ sudo lscpu
Vendor ID:                AuthenticAMD
  Model name:             AMD EPYC XXXX X-Core Processor
    CPU family:           26

Fixes: 81d6de9 ("lscpu: remove the old code")
Co-developed-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Pratik R. Sampat <pratikrajesh.sampat@amd.com>