I didn't test it enough after changes apparently...

Mark values as "Auto" and show one from swapchain if available.

Controls are visible only if target swapchain reports different values.

It was impossible to change "zero" value which is 1e-7 and calculated
step was very small.

`pl_color_space_nominal_luma` resets `min_luma` to 0 for PQ output. Even
though our HDR override values were used, min value were reinfered. Use
user input directly.

Scraps the old 2D LUT design by a naive approach which simply updates
the detected HDR metadata in real-time based on measured values, before
feeding it into the tone mapping function.

Also increase the size of tone-mapping LUTs, now that we no longer need
to generate 2D textures.

Removes the support for the custom peak detection object, and instead
merely displays the average brightness from the HDR10+ metadata. This
will no longer be needed, very soon.

The default BPC is good enough for overlays, no need to generate a full
LUT here. Inverse tone-mapping of overlays is probably never intended,
anyway. This will definitely break some sort of HDR anime softsubbed
signs, but not only is the subbing scene dead, this would require HDR
subtitle formats to start existing. (And for the love of god, somebody
just move softsubbed signs to an actual video track already!)

Fixes: https://github.com/mpv-player/mpv/issues/11345

When only scene brightness metadata is available, pick the new spline
instead of HDR10+.

Insteaed of using a hard-coded knee point with slope 1, infer the knee
point from brightness metadata using the st2094 knee point logic. Change
the parameter to an arbitrary subjective contrast enhancement,
defaulting to the slope provided by the knee point enhancement.

Do this logic in PQ space instead of raw nits, to make it more tunable
and perceptually accurate. sqrt(A * B) from the nits formula has been
replaced by mix(A, B, 0.5). This is roughly equivalent because nits were
linear while PQ is quasi-logarithmic, but more importantly, is more
easily tunable.

Mostly for debugging purposes to see how slow display reacts to metadata
changes.

This allow `vk_sw_recreate(sw, 0, 0)` to correctly recreate swapchain
when needed with previous size. Without this change expected size was
not set and recreation failed.

Replace the "Auto" label by a more informative label than "unknown" if
the colorspace information is signalled by the swapchain.

Instead of these complicated bools and structs that get updated from
different places at diferent times, simplify this set of fields into
something easier to understand: `force_*` fields which simply
hard-override their respective values if present.

Rather than updating from multiple places, we thread the configured
target swapchain directly into the `update_settings` function so we can
use it directly as the basis for our configured HDR levels, including
displaying the actually-signalled values *as-is* in the absence of an
override.

We also allow the ICC luma hack to be configurable, forcing
icc_params.max_luma to always be either the detected luminance or the
configured luminance (falling back to the default SDR luminance).

Until we support signalling this to the display, we need to whitelist
here to prevent returning unsignalled properties back to the user.

It makes no sense to re-return HDR metadata that we never signalled to
the display, so strip it here to whitelist only properties that we
actually support signalling to the display.

Due to a multitude of problems and corner cases, I became very unhappy
with the way this field was handled, and decided to re-remove it. I
don't think this affects any API users, so I won't bother with a
deprecation period.

The downside of using a function like this is that we increase CPU work
on every usage site, but I don't really care about micro-optimizing
this. (And the fact that `min_luma/max_luma` get defaulted to their
detected values anyway at the beginning of pl_renderer makes this not so
bad)

One possibly unintended consequence of this change is that
`pl_shader_(de)linearize` now default to SDR gamma even on empty
structs. This is probably intended semantics, though our test framework
does need to be changed to prevent it from exploding due to the implicit
clipping semantics.

Instead of just blindly taking the PL_MAX3() of this array. This should
serve to hopefully fix a disconnect between what we consider to be the
relevant metric (max luminance) and what HDR10+ thinks is important
(maximum component).

Arguably, doing it this way is worse for PL_TONE_MAP_RGB, but since we
default to the BT.2446a-style PL_TONE_MAP_LUMA methods, this should give
us better results in practice.

A smarter man would probably disable testing older GLSL versions on
llvmpipe.

As these can change due to dynamic metadata etc.

Parallels to SH_FLOAT for stuff we expect to be dynamic.

Using 0.5 here is ambiguous as it falls exactly in between 0x7F and
0x80. This test was effectively relying on rounding-up behavior.

Fixes: videolan/libplacebo#247

This was never actually tested before now.

When re-using existing shaders, we now ignore the string builders, and
defer execution to the case where the shader needs to be rebuilt.

This commit needs a lot of special care to ensure that we don't conflate
pass *signatures* (which are now based on the output of
pl_str_builder_hash, unstable values that aren't expected to persist
across program invocations) and the hash used for shader cache entries,
which require some special finesse to ensure their values don't change
as a result of this change.

I've tested this commit to make sure that cached_program entries receive
the exact same hash as before.

Not much exciting happening in this commit, since it doesn't actually
save any work yet. That will happen in an upcoming commit, which will
make `pl_shader_finalize` defer GLSL templating until required.

Instead of building a pl_str directly. This opens up the opportunity to
avoid having to template strings altogether in the future, as well as
allowing us to use more efficient string templaters (such as the output
of a preprocessing stage with #pragma GLSL macros).

Will replace `pl_str` inside `pl_shader`, with the ultimate goal of
making shader construction more efficient.

Formats arguments directly from memory. Useful for wrapping printf-style
calls into a pl_str_builder.

And also condense the logic slightly by coalescing these calls into a
common base case for most data types.

To avoid overhead of adding a bunch of redundant \0 terminators in cases
when we want to frequently append small strings, such as inside
pl_str_append_asprintf_c.

Also changes pl_str_append to always emit the \0 even when appending an
empty string, so it can effectively be used as a way to force strings to
be \0-terminated at the end of such a function.

Inside MinGW env things from within this env should be preferred to
avoid issues with mixing different versions.

Fixes: https://github.com/haasn/libplacebo/issues/153

To fix warnings during vf_libplacebo build

Puts compound literals data into read only section. No need to bloat
.data.

It is not used anywhere else.