expressions: introduce type system

[Totktonada]

• Decide whether we'll borrow graphql type system or introduce our own.
  • Decide on type system.
  • Decide on type nodes implementation.
  • Elaborate whether we can reuse some graphql type checking code.
• Compile-time expression type validation.
  • Don't forget null/non-null checks.
  • Plus: uppermost expression must be boolean.
• Runtime expression value / operands check.
  • Say check for too large integer values, that cannot be represented precisely with number lua type.
  • Support long type represented with number64 (cdata<int64_t/uint64_t>.

It is follow up of #13.

From #13:

Each operation argument should have set of allowed types. Say, 'number' for a
+, -, <, >, 'boolean' for ||, &&, !, 'number' and 'string' for == and != as
well as a type of result.

A root expression must have the boolean type, because it will be used as the
predicate todecided whether an object should be filtered in.

It seems that we should take care of nullability of a type: say, regexp will
not work with null as an argument, but is_null will do.

[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