keygen: explicitly allow application to specify salt

[kwantam]

I propose modifying the KeyGen procedure to make the salt application specified. This has a few benefits:

• Different applications can fix salts to orthogonalize their keys from one another. In principle this is already possible with key_info, but forcing applications to orthogonalize with key_info raises questions about how key_info should be encoded to ensure, e.g., that different applications don't accidentally end up with prefixes of each other's key_info strings (which could end badly). We can avoid this entirely by making the salt application specified.
• Spec v4 broke backwards compatibility with spec v2. While in principle there's a reason for this, in practice v2 is already deployed. Allowing application-specified salt makes it possible to choose either v2 or v4 compatibility.
• We can move the salt = H(salt) invocation to after the HKDF invocation in the pseudocode, which naturally builds in a very very minor optimization.

To be clear, the goal is to maintain full spec and implementation compatibility with v4. Here's a proposed change to keygen:

SK = KeyGen(IKM)

Inputs:
- IKM, a secret octet string. See requirements above.

Outputs:
- SK, a uniformly random integer such that 1 <= SK < r.

Parameters:
- salt, an octet string.
- key_info, an optional octet string. If key_info is not supplied, it defaults to the empty string.

Definitions:
- HKDF-Extract is as defined in [RFC5869](https://datatracker.ietf.org/doc/html/rfc5869), instantiated with hash H.
- HKDF-Expand is as defined in [RFC5869](https://datatracker.ietf.org/doc/html/rfc5869), instantiated with hash H.
- I2OSP and OS2IP are as defined in [RFC8017, Section 4](https://datatracker.ietf.org/doc/html/rfc8017#section-4).
- L is the integer given by ceil((3 * ceil(log2(r))) / 16).

Procedure:
1. while True:
2.     PRK = HKDF-Extract(salt, IKM || I2OSP(0, 1))
3.     OKM = HKDF-Expand(PRK, key_info || I2OSP(L, 2), L)
4.     SK = OS2IP(OKM) mod r
5.     if SK != 0:
6.         return SK
7.     salt = H(salt)

Notice that, by specifying salt = H("BLS-SIG-KEYGEN-SALT-"), the above is compatible with v4; whereas by specifying `salt = "BLS-SIG-KEYGEN-SALT-", it is compatible with v2. We can also add suggestions for how to pick a good salt.

[kwantam]

Ah, just wanted add a note: Bram Cohen brought to my attention that Chia has already deployed the v2 spec. That's what got me thinking about this.

See #28, #26, and #25 for prior discussions of KeyGen.

---

BTW: in discussing "how to pick a good salt," we probably want to mention that HKDF analysis really wants a uniform random bitstring, so that is RECOMMENDED. (But it should not be REQUIRED, because if one willing to make stronger assumptions about H then one can use a "structured" bitstring as in v2. In v4 the statement was just that we didn't want to build those stronger assumptions into the spec.)