Introduce a type for the Fast-Path header

[derfian]

Allow access to Fast-Path header fields through a dedicated type. This reduces the amount of binary arithmetic with semi-magic constants scattered around the codebase.

This is a follow-up to 08c293b, in which I introduced a FIXME.

[derfian]

On second thought... After reading more about endianness and bit field structs, I get the impression that this isn't portable to big endian systems. Can anyone with more C experience/knowledge confirm that this is the case?

[uglym8]

@derfian I'll check it.

[uglym8]

I must admit my first impulse was to say that this is OK.

There is no alignment issues and ,come on, it's just byte-based bitfield struct.
It's naturally to think that endianess should be concerned only for multibyte data types.

But after digging deeper I began to believe that C standard doesn't guarantee any particular order for storing bitfields even for bytes, let alone uint16, uint32 etc.
It's governed solely by compiler.

So to be on the safe side we should use shifts instead of bitfields.

Or, we can still use bitfields, but with one additional runtime check:
Whether this particular architecture (compiler actually) we're running rdesktop on is packing bitfields in the way we expect?

References:
https://stackoverflow.com/questions/6043483/why-bit-endianness-is-an-issue-in-bitfields