Due to a relatively recent change in varnish-cache, VDP_Close() in the
parallel esi thread can race VDP_Deliver in the deliver thread,
resulting in a panic.

See #19 for details

With this change,

	pesi.set(onerror_continue, true);

can be used to restore behavior from before varnish-cache 7.3.

See pesi.set() documentation for details.

The test case is a modified version of the one by Geoff Simmons posted
in https://github.com/varnishcache/varnish-cache/issues/4053#issuecomment-1936000064

this also fixes a build issue introduced by Varnish-Cache
13cf51e70c00b912ce39110d7eff50ccc01b7bb9

fixes https://github.com/varnishcache/varnish-cache/issues/3958

Ref #15

and check that the setting is actually applied (it is).

Now that only the top thread delivers, we can remove the
support for multiple unpending and delivering threads.

This concludes the fix for !11

Some bits were already implemented in previous commits.

See https://github.com/varnishcache/varnish-cache/issues/3938 for why
this took so long.

Also implemented a fix for https://github.com/varnishcache/varnish-cache/issues/3939
(which is not yet in varnish-cache)

In order to properly handle vped_include() failing, we need a way to
insert a node only when it's ready and free it when not.

Thus, we link to the parent in node_new(), but do not insert the
child to the parent's list. As before, this happens in node_insert.

On the way, we also add node_free() to free a node without finalizing
it.

Partly fixes !11

Related prep-work for !6

found by flexelint

Now that we got rid of front unpending, we can also remove all
the complications due to the ST_OPEN state.

Begin with removing that state itself.

It was effectively removed in 913c4653 but
dead code was left until now.

found by flexelint

Found by flexelint

Ever since the first release of vmod_pesi, we knew that this feature
was probably not useful: As explained in the THREADS section of the
vcc / man page, we can not push to VDPs, so the only case where this
could work was when there are no VDPs. The only case pESI itself does
not need any is non-esi, non-gzip uncacheable streaming. Also, the
only case where it made a significant difference from pushing from the
level 0 / front thread was when there are no threads available and the
front thread runs the current include.

Since then, we never encountered a situation where we would have
needed this feature.

Now we can keep references also to private leaf objects.

For ESI objects, which we also need to inspect when building the
delivery tree, we still need to make copies in pesi_buf_bytes because,
if the final flag to ObjIterate() is set, the storage engine can (and
usually will) free segments "behind" delivery.