Remove the concept of byte order from StructNlAttr.

Structures don't have byte orders, only fields have byte orders.
StructNlAttr stores a byte order internally to support netlink
attributes that contain only an iteger.

This is not really a common use case. Also, continuing to store
the byte order inside StructNlAttr means that when parsing
nested structures, the byte order needs to be passed to peek()
and findNextAttrOfType. This is very clunky given that most
attributes won't have an endianness.

Instead, remove the concept of byte order from the object
altogether. If a caller wants to read a StructNlAttr that
contains an integer, they must now call different methods
depending on whether the integer is big endian or native
order.

Callers that want to create a StructNlAttr from an integer of
known byte order already meeded to specify that order when
constructing the object, and this does not change.

Test: atest NetworkStackNextTests
Change-Id: I97345d29529e087e94c86ee82af06e371876d7cc