kernel/sched: Panic after aborting essential thread, not before

The essential thread check and panic happens at the top of
k_thread_abort().  This is arguably a performance bug: the system is
going to blow up anyway no matter where we put the test, we shouldn't
add instructions to the path taken by systems that DON'T blow up.

But really it's more of a testability/robustness glitch: if you have a
fatal error handler that wants to catch this panic (say, a test using
ztest_set_fault_valid()), then the current code will panic and
early-exit BEFORE THE THREAD IS DEAD.  And so it won't actually die,
and will continue on causing mayhem when presumably the handler code
expected it to have been aborted.

It's sort of an unanswerable question as to what the "right" behavior
is here (the system is, after all, supposed to have panicked!).  But
this seems preferable for definable practical reasons.

Kill the thread, then panic.  Unless it's _current, in which case
panic as late as possible for maximum coverage of the abort path.

Fixes: #84460

Signed-off-by: Andy Ross <andyross@google.com>