Odd union for ack/nak counters

[jphickey]

Union is declared here: https://github.com/nasa/CF/blob/a894069439316ef89ad7751f3a03036930158a07/fsw/src/cf_cfdp.h#L137-L141

This counter is then used in the TxS2/RxS2 state data structures.

It should not be necessary to create a union between the unsigned and uint8 types for two reasons:

• unsigned is not a known/guaranteed range type, and the rollover point of this value is not guaranteed. FSW discourages use of types which do not have fixed range unless for valid reasons (e.g. interfacing with library code that uses this type)
• uint8 is simply the 8 LSBs of the value, there is no need to unionize in order to be able to count both modulo 256 as well as a longer type

In short, declaring a union like this has no benefit at all, but only introduces the possibility of accessing it wrong and getting undefined behavior. Only downsides, no upside.

Recommendation is to replace with a normal uint32 counter.

[jphickey]

Upon further inspection, it looks like both the ack and nak states are limited by ack_limit and nak_limit, respectively, in the configuration table. Both limits are uint8 types. So the counter can be uint8, not uint32 (and since these are in the transaction structure, of which there are many instances, this saves a bit of memory).