[Feature] protocol: Expose custom metadata for /checkv3

[Feature] protocol: Expose custom metadata for /checkv3

Add two complementary ways to read custom fields sent with a /checkv3
multipart scan request, both free of the 80KB HTTP header limit that v2
hits, since the metadata travels in the multipart body:

  * A "headers" sub-object in the metadata part is injected into the
    task request headers, so task:get_request_header() works for custom
    fields exactly like v2 HTTP request headers. Reserved control-header
    names (shm/file/path/dictionary/Content-Encoding...) are skipped so
    client metadata cannot collide with the message-loading channel, and
    a repeated name (collapsed by UCL into an array) expands to a
    multi-valued request header.

  * The parsed metadata object is kept on task->meta and exposed to Lua
    via task:get_metadata() and task:get_metadata_field(key), mirroring
    get_settings()/lookup_settings(). The task now owns the object and
    frees it once in rspamd_task_free instead of via a pool destructor.

rspamc gains a repeatable --metadata-header KEY=VALUE option that builds
the metadata "headers" sub-object for v3 requests. Also drop a dead
is_msgpack variable in the v3 request handler.

Tests: functional cases in 430_checkv3.robot plus a checkv3_meta.lua
plugin exercising both options via raw multipart and rspamc.