Refine along fitted line for faster BC1 encoding

[RunDevelopment]

This PR implements an idea I had a while ago to make BC1 encoding faster.

The reason BC1 encoding is so slow is that the refinement algorithm I implemented is very expensive for 3 color channels (dimensions). However, it's quite fast for 1 dimension. So the idea is: instead of trying out endpoint variations in 3D space, vary the distance of the endpoints from their midpoint.

This works surprisingly well. It can't reach the quality of refinement in 3D space, but it also doesn't have to. Since line refinement is about 3x faster than 3D refinement, I can use line refinement to cut down the number of iterations 3D color refinement has to do. So I can improve performance, while keeping the quality the same.

And that's exactly what I did. I changed the parameters of BC1 encoding to have similar levels of quality, while being faster thanks to line refinement:

Quality	Old	New	Change
Fast	726.89 µs	731.83 µs	+0.8483% (noise)
Normal	4.2644 ms	2.2376 ms	-47.528%
High	11.936 ms	10.824 ms	-9.3164%
Perceptual Normal	7.3608 ms	3.7490 ms	-49.068%

(Fast quality isn't affected, because it doesn't do any refinement.)

[RunDevelopment]

I changed the parameters again and now the Normal quality mode doesn't do any regular refinement at all anymore, just line refinement. This makes encoding with normal quality 2x faster now and with virtually no loss in quality.

[RunDevelopment]

I spend some more time integrating the least square optimizing from #79 into this PR. This worked quite well. The encoder is now faster and produces images of higher quality. A win on all fronts.

Quality	Old	New	Change
Fast	726.89 µs	731.83 µs	+0.8483% (noise)
Normal	4.2644 ms	2.1769 ms	-48.952%
High	11.936 ms	11.433 ms	-4.2141%
Perceptual Normal	7.3608 ms	3.5639 ms	-51.583%

The only "downside" is that the speed improvement for High quality isn't as much. But I think that's a reasonable tradeoff for better quality.