Use custom ids for timelock docs section titles

(cherry picked from commit 7d02933da3)

contracts/access/README.adoc

@@ -19,6 +19,7 @@ This directory provides ways to restrict who can access the functions of a contr
 
 {{TimelockController}}
 
+[[timelock-terminology]]
 ==== Terminology
 
 * *Operation:* A transaction (or a set of transactions) that is the subject of the timelock. It has to be scheduled by a proposer and executed by an executor. The timelock enforces a minimum delay between the proposition and the execution (see xref:access-control.adoc#operation_lifecycle[operation lifecycle]). If the operation contains multiple transactions (batch mode), they are executed atomically. Operations are identified by the hash of their content.
@@ -32,6 +33,7 @@ This directory provides ways to restrict who can access the functions of a contr
 ** *Proposer:* An address (smart contract or EOA) that is in charge of scheduling (and cancelling) operations.
 ** *Executor:* An address (smart contract or EOA) that is in charge of executing operations.
 
+[[timelock-operation]]
 ==== Operation structure
 
 Operation executed by the xref:api:access.adoc#TimelockController[`TimelockControler`] can contain one or multiple subsequent calls. Depending on whether you need to multiple calls to be executed atomically, you can either use simple or batched operations.
@@ -51,6 +53,7 @@ const data = timelock.contract.methods.grantRole(ROLE, ACCOUNT).encodeABI()
 
 In the case of batched operations, `target`, `value` and `data` are specified as arrays, which must be of the same length.
 
+[[timelock-operation-lifecycle]]
 ==== Operation lifecycle
 
 Timelocked operations are identified by a unique id (their hash) and follow a specific lifecycle:
@@ -68,14 +71,17 @@ Operations status can be queried using the functions:
 * xref:api:access.adoc#TimelockController-isOperationReady-bytes32-[`isOperationReady(bytes32)`]
 * xref:api:access.adoc#TimelockController-isOperationDone-bytes32-[`isOperationDone(bytes32)`]
 
+[[timelock-roles]]
 ==== Roles
 
+[[timelock-admin]]
 ===== Admin
 
 The admins are in charge of managing proposers and executors. For the timelock to be self-governed, this role should only be given to the timelock itself. Upon deployment, both the timelock and the deployer have this role. After further configuration and testing, the deployer can renounce this role such that all further maintenance operations have to go through the timelock process.
 
 This role is identified by the *TIMELOCK_ADMIN_ROLE* value: `0x5f58e3a2316349923ce3780f8d587db2d72378aed66a8261c916544fa6846ca5`
 
+[[timelock-proposer]]
 ===== Proposer
 
 The proposers are in charge of scheduling (and cancelling) operations. This is a critical role, that should be given to governing entities. This could be an EOA, a multisig, or a DAO.
@@ -84,6 +90,7 @@ WARNING: *Proposer fight:* Having multiple proposers, while providing redundancy
 
 This role is identified by the *PROPOSER_ROLE* value: `0xb09aa5aeb3702cfd50b6b62bc4532604938f21248a27a1d5ca736082b6819cc1`
 
+[[timelock-executor]]
 ===== Executor
 
 The executors are in charge of executing the operations scheduled by the proposers once the timelock expires. Logic dictates that multisig or DAO that are proposers should also be executors in order to guarantee operations that have been scheduled will eventually be executed. However, having additional executor can reduce the cost (the executing transaction does not require validation by the multisig or DAO that proposed it), while ensuring whoever is in charge of execution cannot trigger actions that have not been scheduled by the proposers.