Update docs (#2168)

* Update docs for ERC20 and ERC721

* Add EnumerableMap to docs

* Update misc guides

* Apply suggestions from code review

Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>

Co-authored-by: Francisco Giordano <frangio.1@gmail.com>

contracts/token/ERC20/README.adoc

@@ -2,48 +2,40 @@
 
 This set of interfaces, contracts, and utilities are all related to the https://eips.ethereum.org/EIPS/eip-20[ERC20 Token Standard].
 
-TIP: For an overview of ERC20 tokens and a walkthrough on how to create a token contract read our xref:ROOT:tokens.adoc#ERC20[ERC20 guide].
+TIP: For an overview of ERC20 tokens and a walkthrough on how to create a token contract read our xref:ROOT:erc20.adoc[ERC20 guide].
 
 There a few core contracts that implement the behavior specified in the EIP:
 
-* {IERC20}: the interface all ERC20 implementations should conform to
-* {ERC20}: the base implementation of the ERC20 interface
-* {ERC20Detailed}: includes the <<ERC20Detailed-name,`name`>>,
-   <<ERC20Detailed-symbol,`symbol`>> and <<ERC20Detailed-decimals,`decimals`>>
-   optional standard extension to the base interface
+* {IERC20}: the interface all ERC20 implementations should conform to.
+* {ERC20}: the implementation of the ERC20 interface, including the <<ERC20-name,`name`>>, <<ERC20-symbol,`symbol`>> and <<ERC20-decimals,`decimals`>> optional standard extension to the base interface.
 
 Additionally there are multiple custom extensions, including:
 
-* designation of addresses that can create token supply ({ERC20Mintable}), with an optional maximum cap ({ERC20Capped})
-* destruction of own tokens ({ERC20Burnable})
-* designation of addresses that can pause token operations for all users ({ERC20Pausable}).
+* designation of addresses that can pause token transfers for all users ({ERC20Pausable}).
+* efficient storage of past token balances to be later queried at any point in time ({ERC20Snapshot}).
+* destruction of own tokens ({ERC20Burnable}).
+* enforcement of a cap to the total supply when minting tokens ({ERC20Capped}).
 
 Finally, there are some utilities to interact with ERC20 contracts in various ways.
 
 * {SafeERC20} is a wrapper around the interface that eliminates the need to handle boolean return values.
 * {TokenTimelock} can hold tokens for a beneficiary until a specified time.
 
-NOTE: This page is incomplete. We're working to improve it for the next release. Stay tuned!
-
 == Core
 
 {{IERC20}}
 
 {{ERC20}}
 
-{{ERC20Detailed}}
-
 == Extensions
 
-{{ERC20Mintable}}
-
-{{ERC20Burnable}}
+{{ERC20Snapshot}}
 
 {{ERC20Pausable}}
 
-{{ERC20Capped}}
+{{ERC20Burnable}}
 
-{{ERC20Snapshot}}
+{{ERC20Capped}}
 
 == Utilities
 

contracts/token/ERC721/README.adoc

@@ -2,54 +2,37 @@
 
 This set of interfaces, contracts, and utilities are all related to the https://eips.ethereum.org/EIPS/eip-721[ERC721 Non-Fungible Token Standard].
 
-TIP: For a walkthrough on how to create an ERC721 token read our xref:ROOT:tokens.adoc#ERC721[ERC721 guide].
+TIP: For a walkthrough on how to create an ERC721 token read our xref:ROOT:erc721.adoc[ERC721 guide].
 
-The EIP consists of three interfaces, found here as {IERC721}, {IERC721Metadata}, and {IERC721Enumerable}. Only the first one is required in a contract to be ERC721 compliant.
-
-Each interface is implemented separately in {ERC721}, {ERC721Metadata}, and {ERC721Enumerable}. You can choose the subset of functionality you would like to support in your token by combining the
-desired subset through inheritance.
-
-The fully featured token implementing all three interfaces is prepackaged as {ERC721Full}.
+The EIP consists of three interfaces, found here as {IERC721}, {IERC721Metadata}, and {IERC721Enumerable}. Only the first one is required in a contract to be ERC721 compliant. However, all three are implemented in {ERC721}.
 
 Additionally, {IERC721Receiver} can be used to prevent tokens from becoming forever locked in contracts. Imagine sending an in-game item to an exchange address that can't send it back!. When using <<IERC721-safeTransferFrom,`safeTransferFrom`>>, the token contract checks to see that the receiver is an {IERC721Receiver}, which implies that it knows how to handle {ERC721} tokens. If you're writing a contract that needs to receive {ERC721} tokens, you'll want to include this interface.
 
 Finally, some custom extensions are also included:
 
-* {ERC721Mintable} — like the ERC20 version, this allows certain addresses to mint new tokens
-* {ERC721Pausable} — like the ERC20 version, this allows addresses to freeze transfers of tokens
+Additionally there are multiple custom extensions, including:
 
-NOTE: This page is incomplete. We're working to improve it for the next release. Stay tuned!
+* designation of addresses that can pause token transfers for all users ({ERC721Pausable}).
+* destruction of own tokens ({ERC721Burnable}).
 
 == Core
 
 {{IERC721}}
 
-{{ERC721}}
-
 {{IERC721Metadata}}
 
-{{ERC721Metadata}}
-
-{{ERC721Enumerable}}
-
 {{IERC721Enumerable}}
 
-{{IERC721Full}}
-
-{{ERC721Full}}
+{{ERC721}}
 
 {{IERC721Receiver}}
 
 == Extensions
 
-{{ERC721Mintable}}
-
-{{ERC721MetadataMintable}}
+{{ERC721Pausable}}
 
 {{ERC721Burnable}}
 
-{{ERC721Pausable}}
-
 == Convenience
 
 {{ERC721Holder}}

contracts/token/ERC777/README.adoc

@@ -1,7 +1,7 @@
 = ERC 777
 This set of interfaces and contracts are all related to the [ERC777 token standard](https://eips.ethereum.org/EIPS/eip-777).
 
-TIP: For an overview of ERC777 tokens and a walkthrough on how to create a token contract read our xref:ROOT:tokens.adoc#ERC777[ERC777 guide].
+TIP: For an overview of ERC777 tokens and a walkthrough on how to create a token contract read our xref:ROOT:erc777.adoc[ERC777 guide].
 
 The token behavior itself is implemented in the core contracts: {IERC777}, {ERC777}.
 

contracts/utils/README.adoc

@@ -16,6 +16,8 @@ Miscellaneous contracts containing utility functions, often related to working w
 
 {{EnumerableSet}}
 
+{{EnumerableMap}}
+
 {{Create2}}
 
 {{ReentrancyGuard}}