Ensure Bit/ByteOrderChange parsers always exist at root
If the dfdl:byteOrder or dfdl:bitOrder properties were not provided,
Daffodil did not complain, and it would not insert a Bit/ByteOrderChange
parser at root. This meant that Daffodil would use a default value,
which in some cases caused incorrect behavior. It also meant that the
check for valid bit and byte orders (e.g. not bigEndian &
leastSignificantBitFirst) never occurred since that only happend in
ByteOrderChange parsers, meaning it could allow invalid bit/byte order
combinations.
This changes Daffodil so the root element will always insert Bit and
ByteOrderChange parsers, ensuring that the validity of the properties
are correct and ensuring correct parsing/unparsing. This means that
byteOrder is now always required, even in some cases where it might not
technically be needed.
This also modifies the initial UState/PState creation to not set
bit/byte order, but to instead rely on the Bit/ByteOrderChange parsers
to always be inserted first thing.
Calculate the approximate length of delimited and pattern lengthKinds for alignment
By assuming the length of delimited and pattern lengthKinds was 1,
Daffodil was unable to optimize out some alignment unparsers, which
could lead to deadlocks.
This changes that so the length of delimited or pattern lengthKinds is a
multiple of the length of the encoding. This allows Daffodil to optimize
out some alignment unparsers and prevent deadlocks.
