Introduce applier thread

It's reported that in master-slave setup replicas often have higher CPU
usage than their replication masters. Moreover, it's easy for a replica
to start falling behind the master.

The reason for that is the additional work load on replica's tx thread  as
compared to master. While master typically splits request processing into 2
threads: iproto, which decodes the requests, and tx, which applies them,
replica performs both tasks in the tx thread.

This is due to replication architecture: replica handles master
connection by a single fiber in the tx thread. The fiber first decodes the
incoming requests and then applies them.

Teach replicas to decode the incoming replication stream in a separate
thread. This way tx thread doesn't waste processing time on row
decoding.

Each applier thread may serve several appliers, and the total number of
applier threads is controlled by a new configuration option -
`replication_threads`, with default value `1` (meaning, a single
thread is spawned to handle all the appliers.

Closes #6329

@TarantoolBot document
Title: New configuration option - `replication_threads`

It's now possible to specify how many threads will be spawned to decode
the incoming replication stream.

The default value is '1', meaning a single thread will handle all
incoming replication streams.

You may set the value to anything from 1 to 1000. When there are
multiple replication threads, connections to serve are evenly
distributed between the threads.