box: enrich ER_READONLY with new details

ER_READONLY used not to have any details about the exact reason
why the instance is read-only. The patch changes that by adding
new fields into the error which explain why the error happened and
even help to avoid it for next requests.

Now from the error object can tell whether it was raised because
of box.cfg.read_only = true, or the instance is an orphan, or it
has election enabled but is not a leader, or the transaction limbo
belongs to another instance.

The alternative to ClientError alteration via error_payload was
not to touch struct error and introduce a new error type
specifically for ER_READONLY via a new C++ class like
ReadOnlyError. But it had drawbacks:

- There may be clients who expect ER_READONLY to have ClientError
  type. For instance, they check err.code == ER_READONLY only for
  err.type == 'ClientError';

- Having to introduce a new C++ class each time when want to add a
  new field into an error has to end. Rather sooner than later.

Closes #5568

@TarantoolBot document
Title: box.error.READONLY new attributes

Users could see the error code as `box.error.READONLY` in `.code`
field of an error object. The error didn't have any other
attributes except common ones like 'type'.

Now from the `box.error.READONLY` error users can see why it
happened. The reasons can be the following:

* The instance has `box.cfg.read_only = true`. Then the `READONLY`
error has at least these fields:
```
tarantool> err:unpack()
---
- reason: config
  code: 7
  type: ClientError
...
```

* The instance is an orphan. It enters that state if number of
connected replicas is < `box.cfg.replication_connect_quorum`. Then
`READONLY` error has at least these fields:
```
tarantool> err:unpack()
---
- reason: orphan
  code: 7
  type: ClientError
...
```

* The synchro queue has an owner which is not the given instance.
It usually happens if synchronous replication is used and there is
another instance who called `box.ctl.promote()`. Then `READONLY`
error has at least these fields:
```
tarantool> err:unpack()
---
- queue_owner_id: <box.info.id of the queue owner>
  queue_owner_uuid: <box.info.uuid of the queue owner>
  reason: synchro
  term: <last known box.info.election.term of the owner>
  code: 7
  type: ClientError
...
```
Note than `queue_owner_uuid` sometimes might be not present.

* The instance has `box.cfg.election_mode` not `off` and it is not
a leader. Then `READONLY` error has at least these fields:
```
tarantool> err:unpack()
---
- state: <box.info.election.state of this instance>
  leader_id: <box.info.id of the leader>
  leader_uuid: <box.info.uuid of the leader>
  reason: election
  term: <box.info.election.term of this instance>
  code: 7
  type: ClientError
...
```
`leader_id` and `leader_uuid` might be absent if the leader is not
known. For example, an election is still in progress. Note, than
`leader_uuid` sometimes might be not present even if `leader_id`
is.

If multiple reasons are true at the same time, then only one is
returned in the following order of preference: election, synchro,
config, orphan.