run acpi_shutdown_final later to give other handlers a chance

For example, shutdown_panic wants to produce some output and maybe take
some input before a system is actually reset.

The change should only make difference for the case of system reset
(reboot), poweroff and halt should not be affected.

The change makes difference only if hw.acpi.handle_reboot is set. It
used to default to zero until r213755 / ac731af5670c7.

Also, run shutdown_halt even later, after acpi_shutdown_final. The
reason for that is that poweroff is requested by RB_POWEROFF | RB_HALT
combination of flags. In my opinion, that command is a bit bipolar, but
since we've been doing that forever, then so be it. Because of that
flag combination, the order of shutdown_final handlers that check for
either flag does matter.

Some additional complexity comes from platform-specific shutdown_final
handlers that aim to handle multiple reboot options at once. E.g.,
acpi_shutdown_final handles both poweroff and reboot / reset. As
explained in 9cdf326b4f, such a handler must run after shutdown_panic to
give it a chance. But as the change revealed, the handler must also run
before shutdown_halt, so that the system can actually power off before
entering the halt limbo.

Previously, shutdown_panic and shutdown_halt had the same priority which
appears to be incompatible with handlers that can do both poweroff and
reset.

The above also applies to power cycle handlers.

(cherry picked from commit 9cdf326b4faef97f0d3314b5dd693308ac494d48)
(cherry picked from commit e4ab361e53945a6c3e9d68c5e5ffc11de40a35f2)