ARROW-15244: [Format] Clarify that offsets are monotonic for binary like arrays
ARROW-15244: [Format] Clarify that offsets are monotonic for binary like arrays

# Rationale
The question of "what are the values of the offsets for non-valid entries in arrays" came up in arrow-rs: https://github.com/apache/arrow-rs/issues/1071 and the existing [docs](https://arrow.apache.org/docs/format/Columnar.html#variable-size-binary-layout) seem to be somewhat vague on this issue.

I looked at three implementations of arrow, and they all seem to assume / validate the offsets are monotonic:
* C++ implementation (I think) also also ensures the offsets are monotonic without first checking the validity array https://github.com/apache/arrow/blob/master/cpp/src/arrow/array/validate.cc#L568-L592
* arrow-rs after https://github.com/apache/arrow-rs/pull/921 (based on the C++) will refuse to create arrays where the array offsets are non monotonic
* arrow2 also ensures that offsets are always monotonic.
https://github.com/jorgecarleitao/arrow2/blob/37a9c758826a92d98dc91e992b2a49ce9724095d/src/array/specification.rs#L102-L119

# Changes
Thus I propose updating the format docs to make the monotonic offsets explicit.

# Background
I think @jorgecarleitao's description on  https://github.com/apache/arrow-rs/issues/1071#issuecomment-998481607, explains the reason why having monotonic offsets is a good idea

> I think that in general the property we seek is: discarding the validity cannot result in UB when accessing the values. This justifies the values buffer of a primitive array is always initialized, and the offsets being valid and in-bounds even in null cases.
>
> The rational for this is that sometimes it is faster to skip validity accesses and only iterate over the values (and clone the validity). I do not recall the benchmark result, but this may explain why string comparison ignores validity and & the bitmaps instead.

Closes #12019 from alamb/alamb/clarify_offsets

Lead-authored-by: Andrew Lamb <02e0a999c50b1f88df7a8f5a04e1b76b35ea6a88@nerdnetworks.org>
Co-authored-by: Antoine Pitrou <8ffbbac03241e3002f35c2a1f358cd318666d6e4@free.fr>
Signed-off-by: Antoine Pitrou <9359a4d812173b65a3a0094cd86363e79731a3c2@python.org>

icexelloss/arrow,laurentgo/arrow,apache/arrow,apache/arrow,apache/arrow,wesm/arrow,apache/arrow,wesm/arrow,icexelloss/arrow,kou/arrow,laurentgo/arrow,kou/arrow,apache/arrow,apache/arrow,laurentgo/arrow,wesm/arrow,wesm/arrow,icexelloss/arrow,kou/arrow,wesm/arrow,laurentgo/arrow,kou/arrow,kou/arrow,kou/arrow,laurentgo/arrow,kou/arrow,icexelloss/arrow,icexelloss/arrow,kou/arrow,laurentgo/arrow,wesm/arrow,kou/arrow,icexelloss/arrow,laurentgo/arrow,apache/arrow,wesm/arrow,kou/arrow,apache/arrow,icexelloss/arrow,wesm/arrow,icexelloss/arrow,kou/arrow,kou/arrow,wesm/arrow,laurentgo/arrow,wesm/arrow,kou/arrow,apache/arrow,apache/arrow,apache/arrow,wesm/arrow,icexelloss/arrow,icexelloss/arrow,laurentgo/arrow,laurentgo/arrow,laurentgo/arrow,wesm/arrow,icexelloss/arrow,laurentgo/arrow,kou/arrow,apache/arrow,laurentgo/arrow,laurentgo/arrow,icexelloss/arrow,apache/arrow,icexelloss/arrow,icexelloss/arrow,wesm/arrow,laurentgo/arrow,wesm/arrow,apache/arrow