- make the test suite actually paste
- remove the ugly copy-paste

Use an existing method to pack a key into a tbuf.
@todo: switch to using a list of keys instead of a buffer
for expire.

- introduce primary_key_validate
- make asserts follow the coding style
- the original patch introduced a regression
in the error message when using a multi-part
key in update/delete: since, in the original patch,
key_validate was invoked before primary-key validation,
the error message changed to a less suitable one. Remove
this.
- an assert that something is not NULL is useless noise,
since a few lines down there's definitely going to be
NULL pointer dereference.

Rename tarantool_pthread.h to tt_pthread.h

This is a pre-requisite for addition of Perl stored procedures.

Minor style edits.

@todo: write the reason why we skip a test when we skip it.

Two significant changes (both arguable, since this patch is about
taste by a large measure):

1) Split tuple_seek() into two: tuple_rewind()
and tuple_seek().

tuple_rewind() simply initializes the iterator and
sets it to 'before-first' position.
tuple_seek() returns a field, and sets the iterator
to the position after the returned field.

Previosly there was only tuple_seek(), which required
tuple_next() to get the field, and it was confusing whether
or not tuple_next() after tuple_seek() is required.
Indeed, the very code I chagned sometimes would
call tuple_next() after tuple_seek() and sometimes would not.

2) Move the return value of the iterator outside
of iteration state.

The advantage of "binding" the out parameters of the iterator to
iterator state is that you bind once, and don't need to supply out
parameters into every call to tuple_next() function. It also makes
it easy to add extra out parameters for bind in the future (field
data type, flags, etc).

This makes "binding" technique popular in database driver
APIs. Binding makes API more stable, which is also
important in drivers.

In this case, however, binding adds for extra lines of code
and (possibly) few extra instructions. Plus, since
this is an internal API which we can change any day,
its stability is not as important. So it seems that for
now we're better of with an API which is a bit
more concise/efficient, and can switch to using binding later,
if needed.