Add libjpeg-turbo as jpeg

[rbsheth]

Adding experimental functionality to see if turbojpeg can replace libjpeg in existing dependencies. Avoiding making turbojpeg the default option.

Something to note is that turbojpeg will generate machine code that may not be portable (ex. with AVX2) but Hunter will still cache and distribute the binaries to similar machines. Perhaps we need to add an architecture flag to the toolchain or the package name.

[hjmallon]

libjpeg_turbo != turbojpeg. They have a page about it (https://libjpeg-turbo.org/About/TurboJPEG).

I think the library should be called libjpeg_tubo everywhere to avoid confusion.

Also I believe (though I am not sure) that libjpeg_turbo should gate its SIMD behind cpuid calls (so at least objects on the same arch (x64, x86, arm64) should be compatible, but I'm not sure about that.

[rbsheth]

@hjmallon Good point, I renamed the PR title to reflect which turbo version we're referring to.

Perhaps keeping the turbo in the version is sufficient as far as Hunter is concerned here? This is a turbo version within the libjpeg package description.

I suppose SIMD could be gated behind cpuid calls, but I'm sure that there are packages that do not gate correctly. I wonder what we should do in those cases.

[hjmallon]

Yeah I'm not sure about that. It's probably a separate issue. I think we have had invalid instruction problems with GRPC between AVX/AVX2 machines before so it's probably not specific to this change.