Until now, more or less the only option to copy data from the VCL
client side to the backend side is through headers, as `bereq.http` is
initialized as a copy of `req.http` (additions to this are the
recently changed `client.identity` and `req.backend_hint`).

We now add the option for vmods to register a callback per `PRIV_TASK`
which can then be used to copy vmod owned data from the client to the
backend side.

Callback registrations are kept on a list hanging off `struct req` on
demand. When a backend request is created, the registered functions
are called in order of registration.

The base memory cost to this is one pointer added to `struct req`. If
no registrations are used, this is the only impact on memory
requirements.
The runtime overhead when no callbacks are registered is close to a
noop: one function call to `vbf_privs_copy()`, which only checks a
pointer (besides the common `CHECK_OBJ_*` argument checks).

Alternatives considered:

A straight forward alternative would be a per `PRIV_TASK` copy
function pointer paralleling the free pointer. This option would
charge every `PRIV_TASK` with an additional pointer. Under the
assumption that `PRIV_TASK` copy operations will be required for
select data only, this option was dismissed. It should be noted though
that this option could be more memory efficient if a relevant
proportion of `PRIV_TASKs` requested copying (one pointer vs. approx 4
pointers for this solution).

Another option was to add an event signalled to vmods for backend
request creation (basically `STP_MKBEREQ`). This would allow for the
same functionality as proposed here, but vmods would be responsible to
track all `PRIV_TASK`s requiring copying themsevles. This tracking
would be similar to what is suggested herein, but without the reuse.