Draft: use tarballs instead of git clone in contribs

Some contribs are downloaded using a simple git clone.

A local .tar.xz is created locally, and the checksum of this local archive was used in the past, but the actual content may depend on a specific git/tar/xz version, so the check was removed by !6161 (merged).

As a result, the source is now only authenticated by the commit SHA-1 instead of a SHA-512 of the archive. Moreover, a contrib can use a "short hash", for example TREMOR_HASH := b56ffce0. If the tremor repository gets compromised, it is trivial to generate a new commit with the same hash.

Since a .tar.gz is always available (AFAIK), I suggest to always use tarballs, and remove download_git in the end.

For now, I just changed x264 and tremor (and removed dead code for x265). If you agree, I can change the 9 remaining contribs using download_git. Some contribs are downloaded using a simple git clone.

I, personally, don't think that removing git altogether is an option as history has proved that there isn't always an archive, besides the issue is xz not git itself.

AFAIK, there are no practical attacks against git with SHA-1 hashes as of yet, specifically pre-image attacks. If that is a concern still, then the first order is to move our actual VideoLAN infra to a version of git with a better hash algorithm. Worrying about SHA-1 in contribs seems like a case of a cart before a horse.

And once that is done, it should be easy to switch contribs to SHA-256. I don't see a reason to stop using git hashes for authentication when tarballs are not available for whatever reason (what @typx wrpte).

That said, we absolutely should use full 32-nibble hashes always, not shortened ones, which are actually susceptible to pre-image attacks.

OK, so let's keep download_git for when tarballs are not available, and use tarballs when they are available, ok?

and using long hashes ?