Byte Order and nested messages

[kanigsson]

Context and Problem Statement

The current implementation of the Byte_Order aspect is broken when nested messages are used. The byte order of the outermost message type will be used throughout. Instead, for each message, the byte order that was specified for this message type should be used for fields of this type, even if this message type is then used as a field type in other messages.

Design

• Internally, Recordflux merges or "inlines" the fields of inner messages into the outer message. This means we need to track byte order per field instead of per message, as this inlining can create messages with mixed byte order. This also means that a message can contain the same type with different byte orders.
• We need to change the interface of RFLX_Generic_Types so that only one variant of Extract and Insert exists, and not one variant per byte order. The byte order is then passed as an additional parameter instead. This permits a single instance of Extract and Insert even if a message uses a type with both byte orders.
• Usage of Extract/Insert needs to be adapted, including sequences of scalars.