Add support for custom headers for REST via config.

[teo-tsirpanis]

SC-49141

Similar to S3 custom header support (#4400) this PR adds support for custom headers in REST request. This allows users to set header via a config parameter instead of the current tildb_context_set_tag. The context set tag does not work in all cases because its not always possible to use the same context, i.e SOMA and VCF python APIs can't pass a TileDB-Py ctx to their respective C++ code.

Big thanks to @Shelnutt2 for implementing this. I added a test and documentation.

---

TYPE: CONFIG
DESC: Add rest.custom_headers.* config option to set custom headers on REST requests.

[eric-hughes-tiledb]

The change suggestions make this PR more compatible with #4994.

• Returning a map requires copying it. It's inefficient and verbose when an in-place initialization in (effectively) the constructor would work just as well.
• The friend declaration is unnecessary when exposing extra_headers as a constant accessor work just as well.

[eric-hughes-tiledb]

Is this PR superseded by #5105, or are we going to merge both?

All changes addressed.

[KiterLuc]

Is this PR superseded by #5105, or are we going to merge both?

Both will be merged everywhere today.

[teo-tsirpanis]

Returning a map requires copying it.

@eric-hughes-tiledb I don't understand the "requires" part. Consider the following snippet:

struct C {
    C() = default;
    C(const C&) = delete;
    C(C&&) = default;
};

C foo() {
    C c;
    return c;
}

It compiles in all three major compilers, whereas if I delete the move constructor it does not.

Regardless, for my own learning, is there a way to guarantee that a return value is moved? I have tried return std::move(x) but got a warning-turned-error saying I should just return x.