Changes

trau_frame cosmetic: fix doxygen comments

Change-Id: I5a69c25c4abeef0b62d92bedc2c56a2d533390c5

trau_frame cosmetic: document exact behavior for C1..C5

For historical reasons, osmo_trau_frame_encode() API has quirky
behavior with regard to output of control bits C1..C5: for some
frame types these bits are set to user-controlled values taken
from fr->c_bits[], yet for other frame types the function fills
in what it "knows" to be the correct frame type code, ignoring
the first 5 bits out of user-supplied fr->c_bits[].  One particular
combination of frame type and direction is even more bizarre,
taking only fr->c_bits[3] while fixing the other 4 C-bits.

Unfortunately this behavior cannot be changed without breaking
API compatibility with previous released versions, i.e., without
breaking external applications that rely on this library behavior.
Therefore, we do the next best thing: thoroughly and succinctly
document these quirks.

Change-Id: Id1824c7cc8845ee2a730d556bec807c3cfa75beb