Revert "st/mesa: Transcode ASTC to BC7 (BPTC) where possible"

This reverts commit 68ef8956.

When trying out transcode_astc=true with BPTC on Asphalt 9, we observed very poor image quality - to the point that basic UI icons were blocky, and buttons with a black border had smeared pixels on the edges. Using DXT5 had no such issues.

I originally suspected there was a bug in the BPTC encoder, but I now believe the issue is deeper than that. The commit that introduced the encoder, 17cde55c, says:

"The compressor is written from scratch and takes a very simple approach. It always uses a single mode of the BPTC format (4 for unorm and 3 for half-floats) and picks the two endpoints by dividing the texels into those which have more or less than the average luminance of the block and then calculating an average color of the texels within each division.

It's probably not really sensible to try to use BPTC compression at
runtime because for example with the Nvidia offline compression tool
it can take in the order of an hour to compress a full-screen image.
With that in mind I don't think it's worth having a proper compressor
in Mesa and this approach gives reasonable results for a usage that
is basically a corner case."

In other words, the reason our BPTC compressor was so fast is that it only implements one of the modes and does a low quality approximation. This honestly should probably be improved somewhat, but the original use case was for online-compression, the uncommon but mandatory OpenGL feature where you can supply uncompressed data and trust the driver to compress it for you (at unknown and uncontrolled quality and speed).

Unfortunately, the compressor as it stands is simply not usable for transcoding ASTC data where we want to preserve the underlying image quality as much as possible.