Saving a string of length N in the database saved it as a string of
length N+1 with a trailing NUL explicitly written into the database and
reading it back resulted in a string of length N+1 too, i.e. it didn't
survive the round trip (notice that this bug only affected vector
operations, scalar ones worked correctly).

Fix this by not writing the trailing NUL in odbc_vector_use_type_backend
and fix the strings returned from odbc_vector_into_type_backend by not
assuming that they're NUL-terminated any more: in fact, they can be, but
they also can be right-padded with spaces, which need to be removed.

Notice that this does mean that we still have a problem with
inconsistent behaviour for the strings with the trailing spaces between
ODBC backend and others: ODBC one will strip them from the returned
strings, but other backends will not. It is not clear what can be done
about it, unfortunately.