Refactor order of actions in guest reboot implementations

[happz]

Things worked, but the code was not easy to understand and follow:

• it wasn't obvious custom reboot command and hard reboots are not compatible;
• it wasn't obvious that custom reboot command can come only from reboot request data stored by tmt-reboot;
• the ordering of hard, soft and soft-with-custom-command was unclear,
• command of reboot() was not the same as command of perform_reboot();
• the relationship between reboot() and perform_reboot() was unclear;
• often all known arguments were passed to super().reboot() or perform_reboot(), which was not incorrect, but harder for humans and linters to reason about;
• docstrings of reboot() methods were incomplete or outdated,
• plugins did not mention their special behavior in docstrings of reboot() method.

To hopefully improve the situation, the patch makes the following changes:

• uses @overload to clearly mark that hard=True means no custom reboot command;
• it makes reboot handling in TestInvocation code more verbose to make the distinction between hard and soft reboots which should make the custom reboot command clearly attached to soft reboots only;
• all reboot() methods now follow the same order of actions: handling hard reboot first, soft reboots second, with less dense code;
• perform_reboot() now accepts "action" callback, not "command", and it is responsibility of reboot() to feed perform_reboot() wit the proper action (running remote command, local command, or calling testcloud API, and so on);
• reduces "blind" passing of known values: super().reboot(hard=hard) is correct, but impossible for a type checker to map to the "hard or custom command" split; using hard=True|False helps linters narrow the situation;
• cleans up docstrings, makes them as same as possible with plugin-specific additions and notes where necessary;
• and mention reboot support levels in plugin docstrings.

Pull Request Checklist

• implement the feature
• write the documentation
• adjust plugin docstring