Returning std::array<uint8_t, N> is better ergonomics for the hashing functions usage, instead of a StringRef:
- When returning StringRef, client code is "jumping through hoops" to do string manipulations instead of dealing with array of bytes directly, which is more natural
- Returning std::array<uint8_t, N> avoids the need for the hasher classes to keep a field just for the purpose of wrapping it and returning it as a StringRef
As part of this patch also change the BLAKE3 class API to match HashBuilder's generic hash API.
I think it would be more in line with LLVM coding standards to expand auto in this case (and others) – see https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable.
My understanding is that auto is fine where the type is obvious from the context (is explicitly available on the same line e.g. with casts), is abstract (T::iterator types), or doesn't matter (e.g. lambdas).