message: Clarify that (Flat|Flex)Buffers do not deduplicate vector elements
  I'm also clarifying that while elements are not deduplicated, vectors
  may contain more than one offset to the same value.
diff: @@ -88,7 +88,9 @@ They start with an `soffset_t` to a vtable. This is a signed version of
  This offset is substracted (not added) from the object start to arrive at
  the vtable start. This offset is followed by all the
  fields as aligned scalars (or offsets). Unlike structs, not all fields
  -need to be present. There is no set order and layout.
  +need to be present. There is no set order and layout. A table may contain
  +field offsets that point to the same value if the user explicitly
  +serializes the same offset twice.
  To be able to access fields regardless of these uncertainties, we go
  through a vtable of offsets. Vtables are shared between any objects that
  @@ -124,7 +126,8 @@ Strings are simply a vector of bytes, and are always
  null-terminated. Vectors are stored as contiguous aligned scalar
  elements prefixed by a 32bit element count (not including any
  null termination). Neither is stored inline in their parent, but are referred to
  -by offset.
  +by offset. A vector may consist of more than one offset pointing to the same
  +value if the user explicitly serializes the same offset twice.
  ### Construction
  @@ -353,6 +356,9 @@ Since this is an untyped vector `SL_VECTOR`, it is followed by 3 type
  bytes (one per element of the vector), which are always following the vector,
  and are always a uint8_t even if the vector is made up of bigger scalars.
  +A vector may include more than one offset pointing to the same value if the
  +user explicitly serializes the same offset twice.
  +
  ### Types
  A type byte is made up of 2 components (see flexbuffers.h for exact values):
  