A new hash algorithm for Git

* performance: Doing char replacing in strings is more CPU intensive than just skipping one single byte and continue using standard functions/libraries. This gets more evident when when considering large repositories like the Linux kernel.

* future compatibility: Shifting a-f chars to another set of 6 other letters will only work 3 more times if only considering lower case letters - 6 letters (a-f) * 4 shifts = 24. So at the 5 change, something new must be done to avoid breaking compatibility. Of course the counter argument is "how often will such new algorithms occur in reality?"; but none of us really knows that for sure - just as we don't know how long a git repository will live and be accessed.

From this article (I've not paid attention to discussions in the git community), it seems like they account for the possibility change it again later on again. So having a prefix possibility with just one prefix or suffix letter makes it possible to change algorithms 26 times, with no performance loss (except the "skip one byte" operation when evaluating the hash). If that is two little, 3 letters gives the possibility for 17576 changes; which is probably enough for most of us alive today - but using 4 letters increases that once again to an even more insane number.

But say you then settle for 4 letters prefix (456.976 possibilities) ... then you're not that far away from {sha256} which is 8 letters, with basically an unlimited amount of algorithm changes. What is inside the {} can be any length while containing a good description of what kind of algorithm in use, without needing to lookup that "AAAC" means SHA512.