box: implement sort_order in indexes

The `sort_order` parameter was introduced earlier but had no effect
until now. Now it allows to specify a sort (iteration) order for
each key part.

The parameter is only applicable to ordered indexes, so any value
except 'undef' for the `sort_order` is disallowed for all indexes
except TREE. The 'undef' value of the `sort_order` field of the
`key_part_def` is translated to 'asc' on `key_part` creation.

In order to make the key def aware if its index is unordered, the
signature of `key_def_new` has been changed: the `for_func_index`
parameter has been moved to the new `flags` parameter and
`is_unordered` flag has been introduced.

Alternative iterator names has been introduced (which are aliases
to regular iterators): box.index.FORWARD_[INCLUSIVE/EXCLUSIVE],
box.index.REVERSE_[INCLUSIVE/EXCLUSIVE].

By the way fixed the `key_hint_stub` overload name, which supposed
to be called `tuple_hint_stub`.

`tuple_hint` and `key_hint` template declarations has been changed
because of the checkpatch diagnostics.

Closes #5529

@TarantoolBot document
Title: Now it's possible to specify sort order of each index part.

Sort order specifies the way indexes iterate over tuples with
different fields in the same part. It can be either ascending
(which is the case by default) and descending.

Tuples with different ascending parts are sorted in indexes from
lesser to greater, whereas tuples with different descending parts
are sorted in the opposte order: from greater to lesser.

Given example:

```lua
box.cfg{}

s = box.schema.create_space('tester')
pk = s:create_index('pk', {parts = {
  {1, 'unsigned', sort_order = 'desc'},
  {2, 'unsigned', sort_order = 'asc'},
  {3, 'unsigned', sort_order = 'desc'},
}})

s:insert({1, 1, 1})
s:insert({1, 1, 2})
s:insert({1, 2, 1})
s:insert({1, 2, 2})
s:insert({2, 1, 1})
s:insert({2, 1, 2})
s:insert({2, 2, 1})
s:insert({2, 2, 2})
s:insert({3, 1, 1})
s:insert({3, 1, 2})
s:insert({3, 2, 1})
s:insert({3, 2, 2})
```

In this case field 1 and 3 are descending, whereas field 2 is
ascending. So `s:select()` will return this result:

```yaml
---
- [3, 1, 2]
- [3, 1, 1]
- [3, 2, 2]
- [3, 2, 1]
- [2, 1, 2]
- [2, 1, 1]
- [2, 2, 2]
- [2, 2, 1]
- [1, 1, 2]
- [1, 1, 1]
- [1, 2, 2]
- [1, 2, 1]
...
```

Beware, that when using other sort order than 'asc' for any field
'GE', 'GT', 'LE' and 'LT' iterator lose their meaning and specify
'forward inclusive', 'forward exclusive', 'reverse inclusive' and
'reverse exclusive' iteration direction respectively. Given example
above, `s:select({2}, {iterator = 'GT'})` will return this:

```yaml
---
- [1, 1, 2]
- [1, 1, 1]
- [1, 2, 2]
- [1, 2, 1]
...
```

And `s:select({1}, {iterator = 'LT'})` will give us:

```yaml
---
- [2, 2, 1]
- [2, 2, 2]
- [2, 1, 1]
- [2, 1, 2]
- [3, 2, 1]
- [3, 2, 2]
- [3, 1, 1]
- [3, 1, 2]
...
```

In order to be more clear alternative iterator aliases can be used:
'FORWARD_INCLUSIVE', 'FORWARD_EXCLUSIVE', 'REVERSE_INCLUSIVE',
'REVERSE_EXCLUSIVE':

```
> s:select({1}, {iterator = 'REVERSE_EXCLUSIVE'})
---
- [2, 2, 1]
- [2, 2, 2]
- [2, 1, 1]
- [2, 1, 2]
- [3, 2, 1]
- [3, 2, 2]
- [3, 1, 1]
- [3, 1, 2]
...
```