Graceful bootstrap in the supervised bootstrap strategy

The new option is added to the box.ctl.make_bootstrap_leader() call:

box.ctl.make_bootstrap_leader({graceful = true})

It checks a presence of a bootstrap leader across other peers first and,
if there are no one, bootstraps the initial database on the current
instance.

Strictly speaking:

• If there are no local database:
  • Start connecting to all the peers from box.cfg.replication
    (without waiting).
  • Wait for one of the three situations:
    • Found a peer with the bootstrap leader flag.
    • Connected to all the peers from box.cfg.replication, but there
      is no one with the bootstrap leader flag.
    • box.cfg.replication_connect_timeout is over.
  • If the bootstrap leader is found, go as a replica. Otherwise, assign
    itself as a bootstrap leader.
• If there is a local database, the call is no-op.

The motivating scenario is when we don't really know, whether the
replicaset is already bootstrapped and want to bootstrap it from the
given instance if not.

The new option doesn't give any protection in the situation, when the
replicaset is not bootstrapped and two instances are simultaneously
trying to gracefully bootstrap it.
Requested by @Totktonada in https://github.com/tarantool/tarantool/commit/a894fca28af3196d06aab898ab78ea5d3d64ac7f.

Start with the box.ctl.make_bootstrap_leader() entry point and the graceful option described in the issue, then review the related box.cfg.replication and replication_connect_timeout behavior. Document the no-local-database flow, the existing-database no-op, and the outcome when a bootstrap leader is found or absent.