Introduce three firmware-specific sets of cascaded remanent data

The size of the remanent data in the stack increases almost every time a feature is added to the EtherNet/IP Core.
Especially for the CIP Security firmware it reaches a size that cannot be send to the host application with on single packet (max size is ~1550).

Therefore, the stack needs to be able to send/receive remanent data to/from the host application (or GenAP) using packet fragmentation for packets HIL_STORE_REMANENT_DATA_IND and HIL_SET_REMANENT_DATA_REQ.

This feature (packet fragmentation) will be required for the CIPSecurity firmware to store CIP file object instances and other stuff.
Currently, the remanent data structure is shared between CipSecurity and Vanilla firmware. This is a limiting factor and needs proper separation. Also, it is really inefficent to have 1500 bytes of remanent data when only ~380 are actually used.

With this ticket, we will do the separation and do all other preparation work in order to support packet fragmentation in GCI (Security) use cases.

Three different subsets of remanent shall exist: Base, Extended and Security.

• Base is for netX52/netX90 Use Case A feature sets, vanilla firmwares
• Extended is for vanilla firmwares which include the file object.
• Security for CipSecurity.

Base is a subset of Extended is a subset of Security.
When the firmware type changes (another variant is flashed, with a different remanent data set), remanent data will be deleted.

GCI and EIPAP are extended by startup parameters to configure the selected remanent data set and allocate acyclic buffers (GCI) of appropriate size.
All further steps towards packet fragmentation will be taken with follow-up ticket PSEIP-888.