Give a warning when configured timeouts look strange

[Totktonada]

Unlikely --test-timeout that is above than --no-output-timeout has any sense.

After PR #302 we'll also have --server-start-timeout, which should be less than --test-timeout.

IOW, --server-start-timeout < --test-timeout < --no-output-timeout.

On the other hand, if one want to pass a large --server-start-timeout, we can issue a warning and automatically increase --test-timeout (--server-start-timeout + 10 seconds) and --no-output-timeout (--test-timeout + 10 seconds) for convenience of interactive work.

And the same in the opposite direction: if lower --no-output-timeout is set, other ones should also be lowered.

(To be done after PR #242 and PR #244.)

Irrelevant points (ones where I changed my mind)

We had the following sentence here:

Unlikely --replication-sync-timeout that is above than --test-timeout have any sense.

replication_sync_timeout value it NOT a lower bound of timeout for going into the 'running' status (box.info.status) — it is irrelevant here at all. An instance can set box.info.status to 'running' before syncing with all upstreams. If the sync will fail, the instance will go into 'orphan' from 'running'.

See tarantool/tarantool#6676 (comment) and below.

We also had the following paragraph:

On the other hand, if one want to pass a large --replication-sync-timeout, we can issue a warning and automatically increase --test-timeout (--replication-sync-timeout + 10 seconds) and --no-output-timeout (--test-timeout + 10 seconds) for convenience of interactive work.

I rewrote it for --server-start-timeout, --test-timeout and --no-output-timeout.

[ylobankov]

I would just check each timeout is greater than each other and the difference between each other is at least 10 (server-start-timeout < test-timeout < no-output-timeout). If not so, just raise an error with the comprehensive message how timeouts should be adjusted.