dpaa2: resolve a DPMAC's SFP transceiver under ACPI too

[yarshure_gmail.com]

Summary

DPAA2_MC_GET_SFF_DEV() looks up the sff(4) device firmware associated with a
DPMAC. Implement it on the ACPI compat layer, mirroring the PHY lookup next
to it: the DPMAC's node names the transceiver in an "sfp" _DSD reference,
which acpi_get_device() turns into a device_t because acpi_iicbus(4) attached
the transceiver to that node when it enumerated it. That is the ACPI
equivalent of the xref registration the FDT front-end does.

The method's documentation said it was implemented on the FDT compat layer
only and returned ENXIO under ACPI, where firmware provided no such
association. That was an assumption about one platform's firmware written
into an interface contract; reword it to describe what the method does.

Depends on D60067

Test Plan

arm64 GENERIC, and a variant with dpaa2/sff as modules.

On a SolidRun CEX7 (NXP LX2160A) under UEFI/ACPI, with an "sfp" reference
added to the DPMAC nodes' _DSD -- see the previous commit for how this
board's firmware was extended for testing -- the lookup resolves:

dpaa2_mc0: dpmac_id 8 mdev dpaa2_mac_dev5 sff dev sfp_acpi0
dpaa2_mc0: dpmac_id 9 mdev dpaa2_mac_dev6 sff dev sfp_acpi1

and the consumer in the next commit reads both modules through it.

The FDT side is the same xref lookup that was already in the tree, behind
"#ifdef not_yet /* No sff,sfp support yet. */" inside
dpaa2_mac_fdt_get_phy_dev(), where it made get_phy_dev() answer with the
transceiver when a DPMAC had no PHY. It moves out into a method of its own
and that block goes away. I have no FDT dpaa2 hardware to exercise it; dsl@
tested an earlier form of this path on a Ten64, in D58258.