Fix libsharpyuv sRGB transfer function

The transfer function is used to go to linear and back during the RGB
to YUV conversion. It affects the result of the conversion but the
difference between different transfer functions is fairly minor so
it won't terribly break the image if the transfer function used during
the conversion does not match the one used to encode the pixels.

Despite almost all images being encoded with the sRGB transfer function,
libwebp (from which libsharpyuv was eventually extracted) originally
used the BT709 transfer function.
According to
https://groups.google.com/a/webmproject.org/g/webp-discuss/c/6wMQrupJNAM/m/bfNWQuUiAQAJ
BT709 was chosen because it produced the best empirical results.
However, when more transfer functions were added to libsharpyuv in
https://chromium-review.googlesource.com/c/webm/libwebp/+/4637883 it
was wrongly assumed that the existing transfer function was sRGB.
Therefore BT709 is currently implemented twice, with "sRGB" actually
implementing BT709, and the real sRGB is not implemented at all.

Note that the default transfer function (`kSharpYuvTransferFunctionSrgb`
which is actually BT709) used a precomputed LUT for performance, while
the other transfer function did not.

In order to keep the same default behavior for callers that do not
specify a transfer function, this change switches the default to
`kSharpYuvTransferFunctionBt709`, which uses the precomputed LUT.

`kSharpYuvTransferFunctionSrgb` is now really sRGB, so callers that
explicitly set the transfer function to this value WILL see a small
output change, as well as a performance hit since this setting no longer
uses a LUT.

Change-Id: Idacbe56e36d50f28689910b12692c0df28c54253