call task_del() from destroy_work_on_stack()
prompted by jcs@ reporting a protection fault trap in
drm_mode_rmfb_work_fn() while playing a youtube video in firefox on a
kaby lake machine. He later saw the same trace on tiger lake.
The previous attempt to avoid this situation by changing work flush
functions from taskq_barrier() to taskq_del_barrier() resulted in
suspend sometimes not working on various intel based thinkpads.
The only code we build which calls destroy_work_on_stack() is in
drm_framebuffer.c so the scope of this change is more limited.
Linux only uses destroy_work_on_stack() for debugging so the workqueue
behaviour still doesn't match.
This version is confirmed to not break suspend on x260 by sthen@ and
x280 by tb@ and still avoids the original problem according to jcs@