pca954x: attach to muxes described by ACPI as well as by FDT

[yarshure_gmail.com]

Summary

pca954x_find_chip() was selected at compile time: with FDT in the kernel it
only ever consulted the device tree, and the device-hints path was compiled
out entirely. An arm64 GENERIC kernel has both FDT and ACPI support and may
be booted either way, so dispatch on how the device was actually described
instead -- an OFW node if it has one, else an ACPI handle, else hints.

ACPI firmware identifies these parts by _HID rather than by a compatible
string; NXP's Layerscape reference firmware declares the on-board PCA9547 as
NXP0002.

While here, register the plain iicbus(4) driver on the mux unconditionally
rather than only in the !FDT case. ofw_iicbus(4) declines a child bus that
has no OFW node, so on a device-tree system the ofw flavour still wins and on
an ACPI one the channels get a bus at all. The hints loop also walked
nitems(part_descrs) - 1, a leftover from when the array had a NULL terminator
it no longer has, so the last part was never matched.

Depends on D60060

Test Plan

arm64 GENERIC, and a variant with iicmux/pca954x as modules.

On a SolidRun CEX7 (NXP LX2160A) under UEFI/ACPI the mux is matched by _HID
and attaches, which it did not before:

pca954x0 <PCA9547 I2C Mux> pnpinfo _HID=NXP0002 _UID=0 _CID=none
         at addr=0xee handle=\_SB_.I2C0.MUX0

with its eight channel buses below it.

The FDT path is unchanged in behaviour: the compatible-string lookup is still
tried first and is still what a device with an OFW node takes. The hints path
becomes reachable at all on a kernel built with FDT, and now also matches the
last entry of part_descrs[], which the "- 1" excluded.