Support destination_collection deducible from a parent object

[Totktonada]

http://graphql.org/learn/schema/#union-types

Current connection format:

{
    name = 'connection_name_bar',
    destination_collection = 'collection_baz',
    type = '1:1',
    parts = {
        {
            source_field = 'field_name_source_1',
            destination_field = 'field_name_destination_1'
        },
        ...
    },
    index_name = 'index_name'
}   

Proposed the second connection format:

{
    name = 'connection_name_bar',
    type='1:1',
    variants = {
        {
           filter = {foo = 1, bar = 'id_1'},
           destination_collection = 'collection_baz',
           parts = {
               {   
                   source_field = 'field_name_source_1',
                   destination_field = 'field_name_destination_1'
               },  
               ... 
            }
            index_name = 'index_name'
         },  
         ... 
     }
}

We can move source_fields upward from variants, but I like the idea of maximum reusability of the current code (for now, at least). The format of 'filter' choosen from the same idea.

• tarantool_graphql (validation): expand connection validation with support of the second connection format;
• tarantool_graphql (graphql schema generation): for such connections: generate all possible types and construct the union as the graphql type of the corresponding connection field;
• tarantool_graphql (resolve functions): expand from parameter of accessor:select() to be list of filter, from pairs, expand collection_name to be list of such collection names (in the corresponding order);
• accessor_general: save select_internal as is, but before invoke it do the following: match parent with filters from the from argument one by one and choose the Nth collection_name from the list collection_name, pass the found collection name and certain from variant to the unchanged select_internal.

Debatable: the avro_schema_changes.org document restricts tag value type to number / string and utilizes type conversion, that seems not good for me. Maybe we must specify tag value as a value of some field, not as a key. I proposed more powerfull way that allows to reuse the existing code of our library as much as possible.