docs: add block/transaction weights to RFC (#3368)

Description
---
Add `Block/Transaction Weight` section to Base node RFC

[Rendered](https://demo.hedgedoc.org/s/WsVGgJFO0)

This section probably raises a lot of questions but hopefully can trigger some discussion around the way we 
weight block/transaction bodies and the way these weightings effect fees.

Some considerations:
- Tari script: increases storage size of the UTXO set, adds computation cost at spend time
- Asset registration: adds bytes to output features, depends on number of template_ids added so we may want to include this in the cost / add a consensus rule on the maximum allowed template IDs
- Performance: the added iterations through the ~~input/~~ output sets add a performance hit at tx/block validation time 

Motivation and Context
---
Formally define block/transaction body weights taking into account TariScript and asset registration  

How Has This Been Tested?
---
N/A docs

RFC/src/Glossary.md

@@ -467,9 +467,8 @@ A Tari Token Wallet is responsible for managing [Digital asset]s and [Tokens], a
 
 [transaction weight]: #transaction-weight "Transaction "
 
-The weight of a transaction / block measured in "grams". Block / transaction weight are defined in the same way:
-`weight = num_inputs * PER_INPUT_GRAMS + num_outputs * PER_OUTPUT_GRAMS + num_kernels * PER_KERNEL_GRAMS`
-where the capitalized values are hard-coded constants.
+The weight of a transaction / block measured in "grams". 
+See [Block / Transaction weight](./RFC-0110_BaseNodes.md#blocktransaction-weight) for more details.
 
 ## Unspent transaction outputs
 

RFC/src/RFC-0110_BaseNodes.md

@@ -138,6 +138,45 @@ Valid transactions are:
 * added to the [mempool];
 * forwarded to peers using the transaction [BroadcastStrategy].
 
+#### Block/Transaction Weight 
+[block-transaction weight]: #blocktransaction-weight "Block/Transaction Weight"
+
+The weight of a transaction / block measured in "grams". Input, output and kernel weights reflect their respective relative 
+storage and computation cost. Transaction fees are typically proportional to a transaction body's total weight, creating 
+incentive to reduce the size of the UTXO set.
+
+Given the target block size of `S` and the choice for 1 gram to represent `N` bytes, we end up with
+a maximum block weight of `S/N` grams. 
+
+To illustrate (these values should not be considered authoritative), with an `S` of 1MiB and `N` of 16, the block and 
+transaction body weights are as follows:
+
+
+|                   	| Byte size 	| Natural Weight         	| Adjust 	| Final                  	|
+|-------------------	|-----------	|------------------------	|--------	|------------------------	|
+| Output            	|           	|                        	|        	|                        	|
+| - Per output      	| 832       	| 52                     	| 0      	| 52                     	|
+| - Tari Script     	| variable  	| size_of(script) / 16   	| 0      	| size_of(script) / 16   	|
+| - Output Features 	| variable  	| size_of(features) / 16 	| 0      	| size_of(features) / 16 	|
+| Input             	|       169 	|                     11 	|     -2 	|                      9 	|
+| Kernel size       	|       113 	|                      8 	|      2 	|                     10 	|
+
+Pseudocode: 
+
+```text
+    output_weight = num_outputs * PER_OUTPUT_GRAMS(53)
+    foreach output in outputs:
+        output_weight += serialize(output.script) / BYTES_PER_GRAM
+        output_weight += serialize(output.features) / BYTES_PER_GRAM
+        
+    input_weight = num_inputs * PER_INPUT_GRAMS(9)
+    kernel_weight = num_kernels * PER_KERNEL_GRAMS(10)
+    
+    weight = output_weight + input_weight + kernel_weight
+```
+
+where the capitalized values are hard-coded constants.
+
 ### Block Validation and Propagation
 
 The block validation and propagation process is analogous to that of transactions. New blocks are received from the