Type the handle_pending_component signature

[chrysh]

Follow-up to #29, now on main.

handle_pending_component took a FirmwareComponent whose comparison stamp,
version string, image size and option flags were dummies, and returned a bare
u8. An implementor could not tell which fields were real, or which completion
codes this command allows.

PendingComponent carries only the three fields the request has, with
downstream_device_index() for the 0xFFFF case. The classification stays a raw
u16, passed through as received, because ComponentClassification does not
name every value that can arrive.

PendingComponentResult has the three outcomes Table 44 allows, and the
estimated time sits in Activated(u16), so it cannot be sent next to the other
two codes. into_response builds the response from it, so the handler never
pairs a completion code with a time itself.

The README section from #29 is updated to match.

Not in here: activate has the same bare-u8 return; if get_firmware_parms
fails this command sends no response at all instead of a completion code; and
the two error outcomes still encode the full response body with
estimated_time zero, where every other handler answers an error through
generate_failure_response with the completion code alone. That last one needs
a DSP0267 Table 44 check on whether the field is present on an error. All
separate.

This is a breaking FdOps change, so openprot's next pin bump needs it on top
of the three methods already pending there.

[CourtneyDrant]

This looks like a better direction to me and I will approve. However, the one thing we need to do is to return an error on 0xFFFF components. "Downstream Devices" have special meaning in PLDM. It means that the terminus is an FDP (Firmware Device Proxy) and not a FD. We have command support for FDPs in pldm-common but not in pldm-interface. In short, we don't support FDPs yet. Can we return InvalidComponentClassification on 0xFFFF Classifications until we do?