HIL_SET_REMANENT_DATA_REQ behaves inconsistently between rcX-based and eCos-based firmwares

In the eCos/GenAP world we expect at least the proper compnent ID in the packet and reject with ERR_HIL_INVALID_PACKET_LEN or ERR_HIL_INVALID_COMPONENT_ID otherwise.

In contrast, the specific AP also accepts a packet with zero length for the state transiition to state 'remanent data available'.

Behavior should be consistent. Mimic the check for invalid packet length and the check for a valid component ID of the GenAP in the specific AP task.