Link fixes and other cleanup

- Clarifies that SetFee transaction hashes weren't always unique
  (Fixes #696)
- Fixes some broken links and adds a couple more useful links.
- Mention different types of transactions in tx basics page
- Fix inconsistent naming of 'list xrp...' use case

content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.md

@@ -343,3 +343,9 @@ For information about how to revoke a master key pair you generated for your val
     - [consensus_info method][]
     - [validator_list_sites method][]
     - [validators method][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/tutorials/manage-the-rippled-server/stand-alone-mode/load-a-saved-ledger-in-stand-alone-mode.md

@@ -1,6 +1,6 @@
 # Load a Saved Ledger in Stand-Alone Mode
 
-You can start a `rippled` server in [Stand-Alone Mode](TODO) using a [historical ledger version](TODO) that was previously saved to disk. For example, if your `rippled` server was previously synced with any XRP Ledger peer-to-peer network including [the production Mainnet, the Testnet, or the Devnet](parallel-networks.html), you can load any ledger version your server had available.
+You can start a `rippled` server in [Stand-Alone Mode](rippled-server-modes.html) using a [historical ledger version](ledgers.html) that was previously saved to disk. For example, if your `rippled` server was previously synced with any XRP Ledger peer-to-peer network including [the production Mainnet, the Testnet, or the Devnet](parallel-networks.html), you can load any ledger version your server had available.
 
 Loading a historical ledger version so may be useful for "replaying" a ledger to verify that transactions were processed according to the rules of the network, or to compare the results of processing transaction sets with different [amendments](amendments.html) enabled. In the unlikely event that [an attack against the XRP Ledger's consensus mechanism](consensus-protections.html) caused unwanted effects to the shared ledger state, a consensus of validators could "roll back" to a previous, known-good network state starting with this process.