docs: fix ERC165 docs and ERC165Checker references

Author: VolodymyrBg

docs/modules/ROOT/pages/utilities.adoc

@@ -46,7 +46,7 @@ function _verify(
     bytes32 s,
     bytes32 qx,
     bytes32 qy
-) internal pure returns (bool) {
+) internal view returns (bool) {
     return data.verify(data, r, s, qx, qy);
 }
 ----
@@ -63,7 +63,7 @@ function _verify(
     bytes32 s,
     bytes32 qx,
     bytes32 qy
-) internal pure returns (bool) {
+) internal view returns (bool) {
     // Will only call the precompile at address(0x100)
     return data.verifyNative(data, r, s, qx, qy);
 }
@@ -191,11 +191,13 @@ For an on-chain Merkle Tree, see the xref:api:utils.adoc#MerkleTree[`MerkleTree`
 In Solidity, it's frequently helpful to know whether or not a contract supports an interface you'd like to use. ERC-165 is a standard that enables runtime interface detection. Contracts provide helpers both for implementing ERC-165 in your contracts and querying other contracts:
 
 * xref:api:utils.adoc#IERC165[`IERC165`] — this is the ERC-165 interface that defines xref:api:utils.adoc#IERC165-supportsInterface-bytes4-[`supportsInterface`]. When implementing ERC-165, you'll conform to this interface.
-* xref:api:utils.adoc#ERC165[`ERC165`] — inherit this contract if you'd like to support interface detection using a lookup table in contract storage. You can register interfaces using xref:api:utils.adoc#ERC165-_registerInterface-bytes4-[`_registerInterface(bytes4)`]: check out example usage as part of the ERC-721 implementation.
+* xref:api:utils.adoc#ERC165[`ERC165`] — inherit this contract and override `supportsInterface(bytes4)`; chain `super.supportsInterface(interfaceId)` when multiple parents are involved.
 * xref:api:utils.adoc#ERC165Checker[`ERC165Checker`] — ERC165Checker simplifies the process of checking whether or not a contract supports an interface you care about.
 * include with `using ERC165Checker for address;`
-* xref:api:utils.adoc#ERC165Checker-_supportsInterface-address-bytes4-[`myAddress._supportsInterface(bytes4)`]
-* xref:api:utils.adoc#ERC165Checker-_supportsAllInterfaces-address-bytes4---[`myAddress._supportsAllInterfaces(bytes4[\])`]
+* xref:api:utils.adoc#ERC165Checker-supportsInterface-address-bytes4-[`myAddress.supportsInterface(bytes4)`]
+* xref:api:utils.adoc#ERC165Checker-supportsAllInterfaces-address-bytes4---[`myAddress.supportsAllInterfaces(bytes4[\])`]
+* xref:api:utils.adoc#ERC165Checker-supportsERC165-address-[`myAddress.supportsERC165()`]
+* xref:api:utils.adoc#ERC165Checker-getSupportedInterfaces-address-bytes4---[`ERC165Checker.getSupportedInterfaces(myAddress, ids)`]
 
 [source,solidity]
 ----
@@ -255,7 +257,7 @@ TIP: While working with different data types that might require casting, you can
 [[structures]]
 == Structures
 
-Some use cases require more powerful data structures than arrays and mappings offered natively in Solidity. Contracts provides these libraries for enhanced data structure management:
+Some use cases require more powerful data structures than arrays and mappings offered natively in Solidity. Contracts provide these libraries for enhanced data structure management:
 
 - xref:api:utils.adoc#BitMaps[`BitMaps`]: Store packed booleans in storage.
 - xref:api:utils.adoc#Checkpoints[`Checkpoints`]: Checkpoint values with built-in lookups.
@@ -292,7 +294,7 @@ function push(bytes32 leaf) public /* onlyOwner */ {
 
 The library also supports custom hashing functions, which can be passed as an extra parameter to the xref:api:utils.adoc#MerkleTree-push-struct-MerkleTree-Bytes32PushTree-bytes32-[`push`] and xref:api:utils.adoc#MerkleTree-setup-struct-MerkleTree-Bytes32PushTree-uint8-bytes32-[`setup`] functions.
 
-Using custom hashing functions is a sensitive operation. After setup, it requires to keep using the same hashing function for every new value pushed to the tree to avoid corrupting the tree. For this reason, it's a good practice to keep your hashing function static in your implementation contract as follows:
+Using custom hashing functions is a sensitive operation. After setup, it requires continuing to use the same hashing function for every new value pushed to the tree to avoid corrupting the tree. For this reason, it's a good practice to keep your hashing function static in your implementation contract as follows:
 
 [source,solidity]
 ----
@@ -346,9 +348,9 @@ function replace(Uint256Heap storage self, uint256 newValue) internal returns (u
 
 === Packing
 
-The storage in the EVM is shaped in chunks of 32 bytes, each of this chunks is known as a _slot_, and can hold multiple values together as long as these values don't exceed its size. These properties of the storage allow for a technique known as _packing_, that consists of placing values together on a single storage slot to reduce the costs associated to reading and writing to multiple slots instead of just one.
+The storage in the EVM is shaped in chunks of 32 bytes, each of these chunks is known as a _slot_, and can hold multiple values together as long as these values don't exceed its size. These properties of the storage allow for a technique known as _packing_, that consists of placing values together on a single storage slot to reduce the costs associated to reading and writing to multiple slots instead of just one.
 
-Commonly, developers pack values using structs that place values together so they fit better in storage. However, this approach requires to load such struct from either calldata or memory. Although sometimes necessary, it may be useful to pack values in a single slot and treat it as a packed value without involving calldata or memory.
+Commonly, developers pack values using structs that place values together so they fit better in storage. However, this approach requires loading such struct from either calldata or memory. Although sometimes necessary, it may be useful to pack values in a single slot and treat it as a packed value without involving calldata or memory.
 
 The xref:api:utils.adoc#Packing[`Packing`] library is a set of utilities for packing values that fit in 32 bytes. The library includes 3 main functionalities: