ir: add BT_CTF_BYTE_ORDER_NONE and make it the default trace's native BO

ir: add BT_CTF_BYTE_ORDER_NONE and make it the default trace's native BO

There's a problem now where you need to explicitly set the native byte
order of a trace you create with bt_ctf_trace_create() with
bt_ctf_trace_set_native_byte_order() before the trace object is frozen,
otherwise the function which would cause the freezing fails.

Some trace formats have no byte order concept. Other properties like
alignment and binary field sizes may have no meaning either. Source
component classes which implement the decoding of those formats should
do a best effort to represent their trace's metadata using CTF IR. That
said, choosing an arbitrary trace's native byte order imposes this byte
order when a ctf.fs sink writes the trace. Here, BT_CTF_BYTE_ORDER_NONE
means that we don't care about the byte order, that it was not
meaningful when decoding the original trace, therefore you can choose
any output byte order you want.

With this patch, the initial trace's native byte order is
BT_CTF_BYTE_ORDER_NONE, and this is a valid byte order when the trace
needs to be frozen. A non-CTF writer trace cannot be used by a CTF
writer object anyway; a CTF writer always creates its own trace object.
The initial native byte order of a CTF writer trace is the machine's
byte order. You cannot set a CTF writer trace's native byte order to
BT_CTF_BYTE_ORDER_NONE. Also, you cannot set any field type's byte order
to BT_CTF_BYTE_ORDER_NONE: it's only valid for a non-CTF writer trace.

libctfcopytrace is modified to only explicitly set the CTF writer
trace's native byte order if the original trace's native byte order is
not BT_CTF_BYTE_ORDER_NONE.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>