Improve FunctionBar code regarding size handling

[Explorer09]

• Demote the FunctionBar.size member from uint32_t to unsigned int type because the value is never meant to be greater than FUNCTIONBAR_MAXEVENTS (== 15).
• (Cherry-picked to main) Add an assertion in FunctionBar_new() to indicate the fact above.
• (Cherry-picked to main) Use size_t for loop iterators (array indices) in all FunctionBar methods. (This change will depend on compiler optimization to keep the same code size. In particular the recognition that a smaller iterator (32-bit) can be used when the limit is constrained to 32-bit integers.)

[BenBE]

The use of uint32_t was intentional to have a minimum of size guarantees for the structure layout.

[Explorer09]

The use of uint32_t was intentional to have a minimum of size guarantees for the structure layout.

I can't get it. What I see is the value would never exceed FUNCTIONBAR_MAXEVENTS and it would not be necessary to use uint32_t. Given that unsigned int is also 32 bits in many processor architectures, the change to unsigned int shouldn't affect structure size.

To prevent further problems with structure alignment (what were addressed in #1702), I moved non-pointer members (size and staticData) to after the pointer members.

[BenBE]

The other option, which I chose was to just fix the size of members so alignment gets resolved that way. Also, I prefer to have integer sizes fixed, unless the API requires otherwise …

I think we can skip the additional shuffling of members and if you just keep the uint32_t we're good to go …

[Explorer09]

I've split the changes of this PR into two commits, so that the part without dispute can be applied (cherry-picked) first.

And I'm still not convinced with keeping the uint32_t type anyway.