Prefer struct bitfields rather than bitshifting and -masking

[Christof Mroz]

Currently, individual bits in HIP packets are accessed via bit-level operations, which led to some minor confusion on the mailing list at least in one instance.
Native C bitfields look like a straightforward solution to improve readability of bit access... at first. It's not that simple, unfortunately.

Note the use of preprocessor conditionals in the glibc "struct iphdr" [1], for example. Why do we care about byte order for a one-octet field? Turns out that the bit order is actually implementation-dependent, and at least in the case of GCC is derived from byte order. I'd suggest reading [2] and [3] for somewhat more details on this.

That said, it's unclear whether we even want to open that can of worms to begin with. Could be a good "excuse" to write some more unit tests, on the other hand. As soon as bit-pattern tests are in place, adopting bitfields should pose a minimal risk.

[1] http://linux.die.net/include/netinet/ip.h
[2] http://stackoverflow.com/questions/864077/why-does-an-8-bit-field-have-endianness
[3] http://stackoverflow.com/questions/1490092/c-c-force-bit-field-order-and-alignment