Introduce the `read_value` function which is able to read a [value], as
specified in the CQL protocol. It will be used in the next commit, in
order to make the interface of the SerializedValue iterators more
correct.

Currently, the SerializedValues' `iter()` method treats both null and
unset values as None, and `iter_name_value_pairs()` just assumes that
values are never null/unset and panics if they are.

Make the interface more correct by adjusting both methods to return
RawValue. The iterators will be used in the next commit to implement the
fallback that allows to implement `SerializeRow`/`SerializeCql` via
legacy `ValueList`/`Value` traits.

… interfaces

Currently, `SerializeRow` and `SerializeCql` traits are just given a
mutable reference to a Vec<u8> and asked to append their CQL
representation to the end. While simple, there are some issues with the
interface:

- The serialize method has access to the serialized representation of
  the values that were appended before it. It's not necessary for a
  correct implementation to have access to it.
- Implementors technically can append any byte sequence to the end, but
  actually are expected to produce a CQL [value] containing the
  serialized value.

While the `SerializeRow` and `SerializeCql` traits are not generally
meant to be manually implemented by the users, we can make the interface
easier to use and harder to misuse by making it append-only, restricting
what the users are allowed to append and requiring the users to append
anything by using a dash of type-level magic.

Introduce `RowWriter` and `CellWriter` traits which satisfy the above
wishes and constraints, and pass them instead of Vec<u8> in
`SerializeRow` and `SerializeCql`.

The new traits have two implementations - a Vec<u8> backed one that
actually appends the bytes given to it, and a usize-backed one which
just measures the length of the output without writing anything. Passing
the latter before doing the actual serialization will allow to
preallocate the right amount of bytes and then serialize without
reallocations. It should be measured whether the reallocation cost
always outweighs the calculation cost before implementing this
optimization.