we will be using it again, but slightly differently

this was intended to weed out additional errors, but right after the
set_closed & unluck, the topreq thread may deliver our node

previously, we called it way too early from within vdp_pesi_fini() /
vdp_pesi_bytes() - see 6632dc5d

but the call from vped_deliver() was still from within the FSM, and we
need to finish additional cleanup in ved_task() before we can let the
topreq thread start delivering and possibly fini'ing / freeing our node.

otherwise the topreq thread cleanup may race us and clean things under
our feet. In this case it should not really have mattered because of the
topreq waiting for the subreq, but anyway, this is how it should be.

We now fini the root pesi while other tasks could still be running

This reverts commit 92621497.

because, as in the case of pretendgz, they may be chaging the next
level up.

e00023 passes now

https://github.com/varnishcache/varnish-cache/issues/3028

fiddling the filters manually really does not make much sense, in
particular not for our test-cases which are supposed to closely match
varnish-cache serial esi behavior

I _suspect_ this caused issues with make failing in dependency tracking
for me, like:

make[2]: Entering directory
'/home/slink/Devel/varnish-git/libvdp-pesi/src'
  CC       vdp_pesi.lo
mv: cannot stat '.deps/vdp_pesi.Tpo': No such file or directory
Makefile:700: recipe for target 'vdp_pesi.lo' failed
make[2]: *** [vdp_pesi.lo] Error 1