Use the same method that we generate private keys in BLS

we could use the same method that we generate private keys in BLS where some 32 bytes entropy bytes are an input, in our case the whole digest. However @asonnino it's very common for rogue key protection to use half scalars, because we care about pre-image attacks; you try to cancel-out another pub key, so combinatorics are already very expensive.

We do use half scalars in many apps (ie in the EdDSA half aggregation) for performance reasons to make that exponentiation half-expensive. In fact though, here we don't care, as this applies once at private key randomization (and with our mode where new-priv_key = old_priv_key \times this_scalar, we don't even have an ECC operation).

@asonnino: You remember the discussion we had at overleaf, shall we update the private key or for each signature we multiply by this scalar? if we do the former half or full scalar doesn't really matter. In the second you have to pay that cost every time you sign.

Originally posted by @kchalkias in https://github.com/MystenLabs/fastcrypto/pull/236#discussion_r1027302408

The payload names no source file or test; start by reading PR #236's discussion and locating the BLS private-key generation and rogue-key-protection entry points. Resolve whether scalar derivation is applied when updating the private key or per signature, and whether full or half scalars are required; done when the chosen behavior is implemented and covered by relevant tests.