DDSIRTP23 — Include the padded bits into the Encapsulation options

Per the resolution of http://issues.omg.org/browse/DDSXTY12-10 the lower 2 bits of the encapsulation options shall be use to encode how many padding bits were added.

This informations should be added to section 10.2.1.2 and an issue should be added to XTYPES 1.3 to remove it from there.

Furthermore to avoid confusion/ambiguities we should be explicit about the endianess used to encode the "ushort options".

Unless this would cause problems to existing implementations I would suggest we either state that the "ushort options" is always serialized using BigEndian or equivalently we change the type to octet[2] instead of "ushort".

The reason is that the alternative interpretation, namely use the endianness implied by EncapsulationIdentifier is not well defined in all cases. Not all EncapsulationIdentifier kinds explicitly select an Endianness. The ones referenced in RTPS: CDR_BE, CDR_LE, PL_CDR_BE, and PL_CDR_LE that are defined in do. But others, including the "XML" defined in XTYPES do not. So RTPS could not make a general statement about the encoding of the "ushort options" unless the statement is to fix the endianess independent of the EncapsulationIdentifier.

Merged with resolution of DDSIRTP23-42

The resolution of this issue has been merged with the resolution of DDSIRTP23-42