iproto: override request handlers using event triggers (part 2)

This patch allows to override IPROTO request handlers by setting triggers
on the corresponding events after the initial `box.cfg{}' call.

Part of #8138

@TarantoolBot document
Title: Document iproto override using event triggers
Product: Tarantool
Since: 3.1
Root document: New page - https://www.tarantool.io/en/doc/latest/reference/reference_lua/trigger/

Since Tarantool 3.1 there are 2 ways to override iproto request handlers:

 1. Using `box.iproto.override()`, introduced in Tarantool 2.11:
    https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_iproto/override/



 2. Using universal trigger registry: tarantool/doc#3988

To override an iproto request handler for the given request type, one can
set a trigger (or multiple triggers) on the corresponding event.

There are 2 types of iproto-overriding events:
 1. set by request type id, e.g.:
     - box.iproto.override[1]
     - box.iproto.override[-1]
 2. set by request type name (the name must be in the lowercase), e.g.:
     - box.iproto.override.select
     - box.iproto.override.unknown

Override-by-id allows to set a handler for a particular request type, that
is not known by the given version of Tarantool. This is not possible with
override-by-name, where a type name must be known by Tarantool. Also there
are a special type name "unknown" and a type id box.iproto.type.UNKNOWN
(== -1) that allow to set a single handler for all unknown request types.

Multiple triggers can be associated with a single event. The triggers are
called in reverse order of their installation, however triggers set by id
are called before triggers set by name.

If a trigger returns `false`, the next trigger in the list is called, or a
system handler if there are no more triggers. If a trigger returns `true`,
no more triggers or system handlers are called.

If some request type is overridden by both interfaces (legacy
`box.iproto.override()' and new `trigger.set()'), the order of invocation
of those handlers is unspecified.

Co-authored-by: Andrey Saranchin <Andrey22102001@gmail.com>