rephrase_validate_limitations (#1361)

Author: ArielElp

components/Starknet/modules/architecture-and-concepts/pages/accounts/account-functions.adoc

@@ -80,8 +80,7 @@ This restriction enforces a single storage update being able to invalidate only
 
 This limitation implies that the fees you need to pay to invalidate transactions in the mempool are directly proportional to the number of unique accounts whose transactions you want to invalidate.
 ====
-* The maximum number of computational steps, measured in Cairo steps, for a validation function is 1,000,000.
-* A builtin can be applied a limited number of times. For specific limits for each builtin, see xref:tools:limits-and-triggers.adoc[].
+* The maximum number of Cairo steps in each of the three validation functions is 1,000,000.
 * The `get_execution_info` syscall behaves differently When raised from one of the `validate` functions:
 ** `sequencer_address` is set to zero
 ** `block_timestamp` returns the time (in UTC), rounded to the most recent hour.
@@ -104,4 +103,4 @@ A transaction has the status `REVERTED` when the `+__execute__+` function fails.
 
 Thanks to account abstraction, the logic of `+__execute__+` and the different validation functions is up to the party implementing the account. 
 To see a concrete implementation, see OpenZeppelin's link:https://github.com/OpenZeppelin/cairo-contracts/blob/v0.14.0/src/account/account.cairo#L72[account component].
-This implementation adheres to link:https://github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-6.md[SNIP6], which defines a standard for account interfaces.
+This implementation adheres to link:https://github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-6.md[SNIP6], which defines a standard for account interfaces.