Better support for the len type

[xairy]

1. Allow to use len to denote the length of any other field of the same struct, not just for buffer/vma/arrayptr fields.

2. Sometimes one of the fields in a struct denotes not the length of the entire struct or the length of some particular field in bytes, but the length in 32-bit words of the length of a few fields. Not sure exactly how to support that, maybe by adding a support of some simple arithmetic for the len type, along the lines of sizeof(field1) / 4.

   A few examples:

   IPv4 packets (https://en.wikipedia.org/wiki/IPv4#Header) contain IHL field, which is "the number of 32-bit words in the header" (the header is variable in size). More over there is a Total Length field, which "defines the entire packet size, including header and data, in bytes".

   Some IPv6 extension headers (https://en.wikipedia.org/wiki/IPv6_packet#Hop-by-hop_options_and_destination_options) contain Hdr Ext Len fields, which is the "length of this header in 8-octet units, not including the first 8 octets" (octet == byte).

[xairy]

3. Many networking protocols expect packet field values to be big-endian. While it's possible to use define KERNEL_CONST_BE htons(KERNEL_CONST) for constants, it's unclear what to do with the length fields.

[xairy]

2 can be resolved by adding a few special types: bytesize4 to denote the size of a filed in 32-bit words and bytesize8 to denote the size of the field in 64-bit words. The IPv4 example is then can be resolved by using bitfields (#72) and bytesize4[parent] and the IPv6 example - by using bytesize8[parent].

[xairy]

3 can be resolved by adding a few more types: int16be, int32be and int64be, which will denote an integer of appropriate bit size that should be converted to the big endian byte order (the value should probably be converted while parsing the templates and generating types).

[xairy]

Bitfields (#72), be suffix and bytesizeN types are now supported.
This can be closed.