Set instances restart to SIGKILL by default

[avtikhon]

Found that some of the instances could not be killed with SIGTERM signal
and it really needed SIGKILL signal to be sure that the instance would
be terminated. Otherwise some tests may fail, like:

  No output during 120 seconds. Will abort after 120 seconds without
output. List of workers not reporting the status:
  - 001_engine [engine/json.test.lua, memtx] at
var/001_engine/json.result:598
  Test hung! Result content mismatch:
  --- engine/json.result	Fri Nov  6 08:35:45 2020
  +++ var/001_engine/json.result	Mon Nov  9 03:48:40 2020
  @@ -596,248 +596,3 @@
   - ok
   ...
   test_run:cmd("restart server default")
  -engine = test_run:get_cfg('engine')
  ----
  -…

Test run uses 'tarantoolctl' tool for commands in format "restart server
default", and 'tarantoolctl' had only single way to kill it using
SIGTERM signal. To implement ability to use it with SIGKILL was added
additional non-mandatory option to stop and restart 'tarantoolctl'
commands, like:

tarantoolctl stop [--signal=SIGKILL]
tarantoolctl restart [--signal=SIGKILL]

This options didn't change the backward compatibility of 'tarantoolctl'
tool, but gave test-run ability to stop and restart instances with
SIGKILL signal:

tarantoolctl restart --signal=9

It helped to fix the issue with hanging instances in the needed tests.

[Totktonada]

If something is wrong with tarantoolctl start, please, provide information, what exactly. We should not blindly change it to tarantoolctl restart without any understanding of the underlying problem. It just counter-intuitive: doing a restart in a method that is named as 'start'. You don't ever leave a comment here: just like it is normal and obvious to do 'restart --signal=9' in a start() method. Argh.

Regarding SIGKILL, the appropriate fix was implemented in PR #186: the commit links exact problems in tarantool and it is obvious how the commit changes the behaviour of the testing system. The testing system issues a warning, when meet the bad behaviour of tarantool, not just 'fix' tarantool's behaviour. Here you changed the place, where old server was not killed for some reason, but the new server with the same script wants to be started in the same directory (on the same worker). Since PR #186 resolves the main problem with stopping stuck instances, the only way to step into the problem is to miss a stop command and try to start a new server. Are you have a case of this kind?

Anyway, it should be implemented just like PR #186: try SIGTERM, wait, issue a warning and kill by SIGKILL. Maybe even it worth to give a warning if we found any old server: it should not occur if a test is written in a right way. Or, maybe, even fail the test that attempts to do this strange sequence of steps. We need a real case of this behaviour to decide.

Past days the kill_old_server() method was more actual: test-run often miss tarantool's and don't stop them; test/var directory was not removed before each testing.

I'll close the PR, because I don't see any prove that a problem exists. Feel free to reopen, when you'll have a reproducer. Don't miss the suggestions above.