Make mapper builder more universal

[ArtDu]

I haven't forgotten about:

• Tests
• Changelog
• Documentation
• Commit messages comply with the guideline
• Cleanup the code for review. See checklist

Related issues:

[akudiyar]

Changing the call method signature seems reasonable, but that's a breaking change and we must notify the customers appropriately. Changing MessagePackMapper parameter types to MessagePackValueMapper also seems reasonable.

But we shouldn't have any raw Objects in the API (List<?> in call and eval is the only exception here because of the compatibility with tarantool-java and also it's a better variant than just Object). ALso I don't get why we change CallResultMapper result types to something else.

[ArtDu]

But we shouldn't have any raw Objects in the API (List<?> in call and eval is the only exception here because of the compatibility with tarantool-java and also it's a better variant than just Object). ALso I don't get why we change CallResultMapper result types to something else.

I added two ways of using with generics and without. Check them.
We need object for universal mapping when return type is uncertain.

[ArtDu]

@akudiyar I probably did all what we discussed. And also I updated PR in springdata(tarantool/cartridge-springdata#124). Please check both PR and give your opinion

[akudiyar]

That's in the much better shape now. I have just three small nitpicks

[akudiyar]

LGTM