[DO NOT MERGE] crypto: derive key image generator & separate {un}biased hash to ec

[j-berman]

In monero-project/research-lab#142 , @kayabaNerve noted the potential bias in Monero's hash-to-point function, and proposed introducing a cleaner unbiased hash-to-point function with the FCMP++ upgrade to maximize bit security. This proposal was discussed further in this MRL meeting, where @kayabaNerve provided additional context for why this property is even more desirable with FCMP++/Carrot to avoid the "burning bug" in potential circumstances specific to FCMP++/Carrot and not RingCT.

With that general context in mind, this PR introduces 3 new core crypto functions:

• biased_hash_to_ec (previously hash_to_ec)
  • This change makes it clear that legacy code uses the "biased" implementation, which should help clearly separate it from the upgraded "unbiased" implementation and help avoid accidental usage for new code.
• unbiased_hash_to_ec
  • Implemented by @kayabaNerve and used to generate key images in FCMP++ / Carrot code.
• derive_key_image_generator
  • This new helper function is used in FCMP++ code for generating I, which is a member of a leaf that enters the FCMP++ "curve tree," and is used to derive the key image (key images are x * I, where x is the one-time priv key used to spend an output). See references to I in the FCMP++ paper (specific commit).

[kayabaNerve]

Used as I for leaves for CARROT outputs and CARROT outputs alone, right? The above is ambiguous if it's used generally within FCMP++, including for legacy outputs which are migrated in.

[j-berman]

derive_key_image_generator is used to generate I for both legacy and Carrot outputs, note the function:

  void crypto_ops::derive_key_image_generator(const public_key &pub, const bool biased, ec_point &ki_gen) {
    if (biased)
      biased_derive_key_image_generator(pub, ki_gen);
    else
      unbiased_derive_key_image_generator(pub, ki_gen);
  }

biased=true for legacy outputs, and biased=false for Carrot outputs.

The scope of this PR (and the intended scope of the audit) are the lines of code specifically included in this PR, and not how they are used in the FCMP++/Carrot integration, which is slated for a later audit round. I was just aiming to provide some general context in that bullet.