Provide a result set object for noSQL API

[Totktonada]

There are several reasons to do so:

• It allow a user to get a value in an exact type (s)he requested. See also this discussion.
• It allows to avoid explicit type convertions on a user's end (now we return results just as List<?> and types inside are mapped from msgpack values).
• This is precondition to support server side cursors in the future (however tarantool does not support them for now).

I think we need to support type convertions under hood at least for integers: say, 16 bits value can be acquired as 32 bits one. We should detect an overflow and raise an exception in the case.

It worth to keep in a mind ResultSet API from JDBC. I hope there are more things that are handled in related JDBC API to aware of, except type conversions.

We may catch an API from the alternative connector: https://github.com/isopov/tarantool-java-driver/blob/88485aca0895f4069517284c6e3e79caf00b0024/tarantool-driver/src/test/java/com/sopovs/moradanen/tarantool/TarantoolClientImplTest.java#L413-L418

[Totktonada]

After #7 we can also provide a way to extract a field from a tuple by its name, not only by an id.

[Totktonada]

Another case, which appears from time to time: a user of the Java connector wants to get binary response data as byte[], but the connector parses msgpack string values into String and may report a unicode decoding error.

[Totktonada]

NB: We should give a user API to unpack call / eval result in the similar way as for a value from a result set.