Merge #203: MuSig doc fixes

dd83e72 Add ordinary tweak info (Jesse Posner)
d26100c Exclude nonce_process from pre-processing steps (Jesse Posner)
b7607f9 Fix reference to xonly_tweak_add (Jesse Posner)

Pull request description:

ACKs for top commit:
  jonasnick:
    ACK dd83e72

Tree-SHA512: b5b94e94625e235557d4a0d9973b14ef74be153b6bdd9a0701add9aa8af4a54411344030db2e65aaac701e3e6a0c1f46190f0d760f7314d426d077959271b615

src/modules/musig/musig.md

@@ -23,7 +23,7 @@ Therefore, users of the musig module must take great care to make sure of the fo
 # Key Aggregation and (Taproot) Tweaking
 
 Given a set of public keys, the aggregate public key is computed with `secp256k1_musig_pubkey_agg`.
-A (Taproot) tweak can be added to the resulting public key with `secp256k1_xonly_pubkey_tweak_add`.
+A (Taproot) tweak can be added to the resulting public key with `secp256k1_xonly_pubkey_tweak_add` and an ordinary tweak can be added with `secp256k1_ec_pubkey_tweak_add`.
 
 # Signing
 
@@ -32,7 +32,7 @@ Essentially, the protocol proceeds in the following steps:
 
 1. Generate a keypair with `secp256k1_keypair_create` and obtain the xonly public key with `secp256k1_keypair_xonly_pub`.
 2. Call `secp256k1_musig_pubkey_agg` with the xonly pubkeys of all participants.
-3. Optionally add a (Taproot) tweak with `secp256k1_musig_pubkey_tweak_add`.
+3. Optionally add a (Taproot) tweak with `secp256k1_musig_pubkey_xonly_tweak_add` and an ordinary tweak with `secp256k1_musig_pubkey_ec_tweak_add`.
 4. Generate a pair of secret and public nonce with `secp256k1_musig_nonce_gen` and send the public nonce to the other signers.
 5. Someone (not necessarily the signer) aggregates the public nonce with `secp256k1_musig_nonce_agg` and sends it to the signers.
 6. Process the aggregate nonce with `secp256k1_musig_nonce_process`.
@@ -42,10 +42,10 @@ Essentially, the protocol proceeds in the following steps:
 
 The aggregate signature can be verified with `secp256k1_schnorrsig_verify`.
 
-Note that steps 1 to 6 can happen before the message to be signed is known to the signers.
+Note that steps 1 to 5 can happen before the message to be signed is known to the signers.
 Therefore, the communication round to exchange nonces can be viewed as a pre-processing step that is run whenever convenient to the signers.
 This disables some of the defense-in-depth measures that may protect against API misuse in some cases.
-Similarly, the API supports an alternative protocol flow where generating the aggregate key (steps 1 to 3) is allowed to happen after exchanging nonces (steps 4 to 6).
+Similarly, the API supports an alternative protocol flow where generating the aggregate key (steps 1 to 3) is allowed to happen after exchanging nonces (steps 4 to 5).
 
 # Verification