Use prefix tree for index lookup everywhere

[Khatskevich]

By now this technique is used only for lookup index for root object fetching.
However, in some cases it can find more suitable indexes even for secondary connections.

Pros:

1. finds more suitable index in some cases
2. one do not have to point out index_name for each connection

Cons:

1. We would have to create index lookup results cache (or smth like this)
2. We have to check that each connection has at least good index on accessor.new phase, or exec time may become surprisingly slow for the gql user

[Totktonada]

Pro ♯2 and con ♯2 are two side of the same coin. More freedom for an user is more headache. I would not allow user anything w/o knowing particular case when it is necessary. From the other side of view, we possibly would need such automation in the scope of #60 (reduce needed configuration effort).

Pro ♯1 seems okay (but need microbenchmarking), con ♯1 is not really con, because of fingerprints approach can gain speedup from such caching too.

[Totktonada]

I'm going to archive the repository. I'll proceed as follows:

• Mark all open pull requests with the archived label and close.
• Mark all open issues with archived and wontfix labels and close.
• Archive the repository.

Consider the following projects:

• https://github.com/tarantool/graphql
• https://github.com/tarantool/graphqlapi
• https://github.com/tarantool/graphqlide