docs: draft RFC-0360: NFT sale via Mimblewimble invoice (#3371)

Description
---
This PR provides a draft RFC for the process to negotiate an NFT sale as an Invoice. This is where the initiator of the transaction requests the payment amount from the counterparty.

Motivation and Context
---

How Has This Been Tested?
---

RFC/src/Glossary.md

@@ -300,6 +300,13 @@ A node ID is a unique identifier that specifies the location of a [communication
 Tari communication network. The node ID can either be obtained from registration on the [Base Layer] or can be derived
 from the public identification key of a [communication node] or [communication client].
 
+## Non-fungible Token (NFT)
+
+[non fungible token]: #nft
+
+A Non-fungible token is a specific instance of a token issued as part of a [digital asset]. It is another name for a
+[digital asset token]. NFTs are contained within specially marked [UTXO]s on the Tari Base Layer.
+
 ## Orphan Pool
 
 [orphan pool]: #orphan-pool "A pool in the Mempool for unconfirmed transactions that attempt to spend non-existent UTXOs"

RFC/src/RFC-0201_TariScript.md

@@ -297,7 +297,7 @@ b_{MRi} &= r_{MRi_b} + e(k_i)
 \tag{5}
 $$
 
-The receiver sends \\( s_{MRi} = (a_{MRi}, b_{MRi}, R_{Mi} ) \\) along with the other partial transaction information to 
+The receiver sends \\( s_{MRi} = (a_{MRi}, b_{MRi}, R_{MRi} ) \\) along with the other partial transaction information to 
 the sender. The sender starts by calculating the final challenge (16) and then completes their part of the aggregated 
 Commitment Signature.