Merge branch '340-data-frag' into 'main'

### An exception for `DATA`.

Data messages may not be fragmented.  (There is never a reason to do

this.)

Data messages may not be fragmented. When packing data into a cell containing

other messages is desired, the application can instead construct a DATA message

of an appropriate size to fit into the remaining space.

While relaxing this could simplify the implementation of opportunistic packing

somewhat (by allowing code that constructs `DATA` messages not to have to know

about packing or fragmentation), doing so would have several downsides.

First, on the receiver side a naive implementation that receives the first cell

of a fragmented `DATA` message would not be able to pass the data in that

fragment on to the application until the remaining cells of that message are

received. An optimized implementation might choose to do so, but that

complexity seems worse than the complexity we'd be avoiding by allowing `DATA`

fragmentation in the first place.

Second, as with any sort of flexibility permitted to implementations, allowing

flexibility here adds opportunities for fingerprinting and covert channels.

### Extending message-length maxima