README.md requested enhancements for new users

Nadie ha tomado este issue todavía.

Please find a list of enhancements to the README.md below for your reference.

# A) Separate the "Step-by-Step Guide" content from "How DevKit works" content.
Ideally a new developer wants to run through Steps 1-X, get to a working example as quickly as possible. However, the current content mixes both alot of educational "how DevKit works" content with the "Step by Step Guide" or "Quickstart" content. This requires a new developer to take much more time to launch an example on DevKit b/c they need to read "all" of the content and learn while doing. (I'm also happy to help you with this reorgnization effort if you like 👍)

# B [Under the Configure Your AVS](https://github.com/Layr-Labs/devkit-cli?tab=readme-ov-file#3%EF%B8%8F%E2%83%A3-configure-your-avs-devkit-avs-config--devkit-avs-context) section:

>"Before running your AVS, you'll need to configure both project-level and context-specific settings. This is done through two configuration files:"

Can we provide more explicit instructions to the user on "which configuration changes they must make, if any for a basic project"? Or can the user skip this step for a vanilla hello world example?

>"Use any popular RPC provider (e.g., QuickNode, Alchemy) to obtain the URLs."

Could we please:
1) Make this more clear that setting the L1_FORK_URL and L2_FORK_URL vars in .env as *explicit steps* using bolding, bulleted lists or otherwise in the Step-by-Step Guide? Currently its nested as plain text, which is very easy for the reader to pass over.
2) Is this really asking for a "Fork URL" or just a working RPC server endpoint? If Fork URL could you provide a link to some other text that explains why a Fork URL is needed? If not, can we just call it an "RPC server endpoint that is used to fork the EVM state to the local anvil instance"?
3) Can we specify which network the user should specify for their FORK URL: Mainnet, Hoodi, Sepolia, or otherwise?
4) For the user can we recommend a few free providers to get them moving quickly, such as https://ethereum-rpc.publicnode.com or https://www.1rpc.io?

# C [Under the Simulate Task Execution](https://github.com/Layr-Labs/devkit-cli?tab=readme-ov-file#6%EF%B8%8F%E2%83%A3-simulate-task-execution-devkit-avs-call) (devkit avs call) section

> devkit avs call -- signature="(uint256,string)" args='(5,"hello")'.

1) Can we explain what this command is doing and what the args represent for the user?

>"Optionally, submit tasks directly to the on-chain TaskMailBox contract via a frontend or another method for more realistic testing scenarios."

2) Can we explain what this is, provide an example and/or a link to "what is TaskMailbox"? This is not obvious for a new user.
Is this step really "Optional"? If so, please consider moving it to the "Optional Commands" section just following it.

3) Add some mechanism for the user to validate the avs call was received by an Operator. Eg you could modify the default main.go code to fmt.Println("ValidateTask: Task ID:", t.TaskId) . Otherwise, the user is sending a call with no mechanism to determine whether or not it was successful.

Empieza con README.md, especialmente con las secciones Step-by-Step Guide, Configure Your AVS y Simulate Task Execution; después, inspecciona el ejemplo predeterminado de main.go y el punto de entrada de la llamada avs del devkit. Aclara el flujo de inicio rápido, los requisitos de configuración y RPC, los argumentos de los comandos, el contexto de TaskMailbox y cómo pueden los usuarios verificar la recepción de la tarea. Se considera terminado cuando un usuario nuevo puede seguir la guía y entender si el ejemplo se ejecutó correctamente.

Escrito por el modelo de indexación a partir del texto del issue.