Whatever.

This function could do with an extra gl_check_err, especially on the
glGetProgramBinary path, since I've observed sporadic failures of that
in the past.

It occurred to me that it really makes no sense to limit the precision
here, and it *has* bitten us in a number of ways, and also caused
general headaches in the form of needing to pass some floats as 1.0/%f
to escape the precision loss.

I seem to have completely forgotten that we actually control the float
printing code and can set the preciison to whatever we want. So just set
it as high as reasonable, because this is intended for machine consumption
anyway.

20 digits gives us enough to cover the ~16 digits of the IEEE mantissa
alongside some extra for the order of magnitude (~11 bits). This really
ought to be enough for everyone.

I can't find any wording anywhere that would imply these are somehow
*not* blendable, so I assume they just always are.

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

Big oops. Closes #122

Allocations/imports got moved from PL_INFO to PL_DEBUG, sub-allocations
(slices) got moved from PL_DEBUG to PL_TRACE.

These happen regularly enough and the code is stable enough that I don't
think it's worth spamming the log anymore.

Closes #120

int -> init

RIP

Because this is actually a rather large release, I kinda feel it's about
time to bump the major version. I still haven't decided if I want to
switch to semver or not to avoid spilling into the three digits, but oh
well. Now it's done, anyways.

A lot of this was kinda dry and out-of-date. Modernize and expand by
emphasizing the kinda cool things libplacebo can actually do.

This is pretty trivial to support, and moves things further in
consideration of #118.

Merging the texture filter with the pl_tex object itself is a left-over
from the mpv RA days. While it involves a different set of tradeoffs, I
think it's far better overall to have this concept separate from the
texture, simply because it allows the shaders to pick their preferred
sample mode dynamically (improving performance in many cases), and in
general reduces the burden on the provider of the textures (i.e. the
user) to set this up.

In addition to splitting this from the pl_tex, we move it to
pl_desc_binding, where it can be changed at runtime. To cut down on
redundancy, we re-use pl_desc_binding for pl_shader_desc as well. Note
that `access` could also live inside pl_desc_binding in principle, but
there's no practical reason to need this because changing the access
mode requires a shader recompilation anyway.

Deprecate all the old fields rather than removing them outright, to
hopefully cut down on the amount of frustration this change will cause.
The `pl_tex_blit` function got params-ified en passant, though, which is
probably the most breaking change amidst this sea of breaking changes.

This logic was old and wrong, because params->upscaler and
params->downscaler might point to the same thing, in which case this can
end up being `true` even when downscaling.

Essentially, this would trigger if both upscaler and downscaler are set
to something like bicubic, in which case downscaling would alias.

This should be <= 4, not < 4.

VkSamplers aren't actually tied to any specific image or imageview, so
we can statically create them on pl_gpu creation and just assign the
correct sampler when updating the descriptor.

This reduces the amount of unnecessary objects per texture
creation/destruction by a grand total of one (1).

Sort of pointless at the moment, but the idea moving forwards is to also
decouple the idea of samplers from the `pl_tex` abstraction entirely.

After holding out against this function for the longest time ever, I
finally stumbled upon a justified use case for its existence:
synchronizing resource destruction of imported textures with external
libraries.

I hope I made it sufficiently clear that this function's existence does
not imply you can skip out on using pl_sync / semaphores.

Should hopefully make issues like #117 easier to debug.

As clarified by @cyanreg, FFmpeg filters are supposed to ignore
obviously "wrong" combinations, in particular RGB + limited range. We
also make an effort to clean up broken sig_peak tagging, since this
exists in practice.

I decided not to sanitize the other paramaters until I encounter a
broken file that demand it, because it's hard to draw the line
otherwise, although we could certainly come up with a few more ideas for
things that are potential candidates. (ICtCp with non-HDR curve? XYZ?)

Also clean up some whitespace because I can't be bothered making a
separate commit for it.

We over-ride this when compiling our own code, though, to avoid
triggering deprecation warnings in our own fallback paths.

As a side-note, also fix the `include` test to include the correct
config.h location.

This is motivated by these two structs, essentially, having
conglomerated into unity. Drop the deprecated fields from each and just
go ahead with the big search & replace.

This also allows us to unify a couple of helper functions, quite
pleasingly. The only really annoying thing is that `target.av1_grain`
makes zero sense, but whatever.

We also provide a new helper function to bridge the "functionality gap"
in the `pl_render_target_partial` / `pl_tex_clear` checks.

An attempt was made to preserve backwards compatibility, for what it's
worth.

The scaler code only checks whether or not the FBOFMT is storable,
but in the case of e.g. draw_overlays, we have to check the actual FBO
(provided by the user) instead.

Solve this by just checking both. (Note: In theory, if the FBO is
storable but FBOFMT is not, this would be a false negative. But
whatever.)

This is a major overhaul of the target rendering code, and the renderer
code in general (to keep things organized and understandable).

The motivation comes from vf_libplacebo, which wants to let users render
out subsampled YCbCr content directly. Unfortunately, we're still pretty
much forced to upconvert to RGB internally, if only for the sake of
things like tone mapping, linear scaling, and so forth. Plus, the entire
pl_renderer architecture is very much designed around the idea that
there's only one plane currently being rendered. While it's not entirely
impossible to change this, it'd be _way_ outside the scope of this
already massive change.

Due to the major change of a core API, I decided to make the old `pl_tex
*fbo` interface merely deprecated, rather than removing it entirely. Due
to the increasing unification between `pl_image` and `pl_render_target`,
I may choose to merge these into a single `pl_frame` at some point in
the future, but that would also imply dropping this bit of backwards
compatibility, so I'll postpone that refactor until after the next major
release.

Pick up a few bugs related to the dithering/compute indirection code
while we're at it.

Added a new test case to make sure it round trips, even for oddly-sized
planes.

Turns out we also need to clamp negative values, specifically for the PQ
function. I'm not sure if both clamps are strictly needed, but I guess
it's better to be safe than sorry.

We can go all the way back to 55.74 by dropping our reliance on
AVCOL_PRI_EBU3213. Fortunately, this is not needed, because the
backwards compatible name AVCOL_PRI_JEDEC_P22 is identical to it.

This includes libavutil-dev, so we can run the libav test.

I have no idea how this is even possible, given that sig is already
clamped to be smaller than sig_peak, but whatever. This brute-force
fixes the issue.

This replaces `int components` by a new `uint8_t component_mask`, which
is more flexible. I decided not to deprecate the original field, because
it doesn't really cause any harm to continue supporting, and in most
cases you don't need the flexibility provided by a mask, so it's just a
hassle.

Made for the sake of allowing us to more efficiently render sub-sampled
planes without needing to waste GPU time scaling unnecessary components
like luma.

The old code tried printf'ing a small float using %f, which resulted in
a rounded literal that was quite far from 1/scale. This led to the image
getting brighter than it should be, globally. The effect was very
significant for higher bit depths.

Fixed this, and improved the precision, by printing exact integer
literals, which get turned into exact float literals by the shader
compiler.

I never seem to get a break with this logic. Anyway, what happened
*this* time was that I noticed `rx`, `ry` were being incorrectly
calculated (they're supposed to be floats, but I was dividing two ints).

I also realized while working through a paper example that using `rx`
for the plane shifts was incorrect to begin with. Fortunately, for most
real-world content, `rx` and `rrx` are identical. For cases where they
aren't, the earlier answer ended up effectively cancelling out this
error, at the cost of an off-by-one (resulting in tiny, probably
unnoticed chroma misalignment).

The correct logic is to use rrx/rry for both. Fixed, and tested. (In
particular, by making sure a YCbCr image survives being converted to
RGB and back to YCbCr by the renderer)

This is technically a hack, or at the very least, some sort of
ID/UD-type behaviour. It works in practice (for good reasons), but
juuust in case, it would really be a smart idea to allow disabling it.

Also swap the order of the error messages to make sure checks happen in
a more sensible order.

After having managed to contrive in my head a scenario in which the luma
plane somehow ends up with luma in an index other than 0 (uploading UYVY
to an rgba8 texture and aliasing it as rg8, the luma information is now
in the G channel), I realized it's a good idea to support this.

It's not really a horrendeous break of API, because the backwards
compatible behaviour is, handily, what you get if you just ignore this
new field's existence.

We load this, but forgot to add it to the recommended_extensions list.

This is a 3DLUT, not a 4DLUT. The alpha channel doesn't exist,
practically.

The av_pix_fmt_desc_get can return NULL which would cause a
NULL-pointer dereference for the has_alpha assignment.

This shader isn't merged with anything else, so no point in forcing it
to be unique. This avoids a double-compilation for planar chroma.

Some API users might erroneously create textures with usage modes that
can't actually be reasonably used, either because the libplacebo
capability is blacklisted, or because of specific cases like storage
support being masked due to lack of unformatted shader storage.