README.md requested enhancements for new users

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.

Commencez par README.md, en particulier les sections Step-by-Step Guide, Configure Your AVS et Simulate Task Execution, puis examinez l’exemple main.go par défaut et le point d’entrée de l’appel avs du devkit. Clarifiez le flux de démarrage rapide, les exigences de configuration et de RPC, les arguments des commandes, le contexte de TaskMailbox et la manière dont les utilisateurs peuvent vérifier la réception de la tâche. Le travail est terminé lorsqu’un nouvel utilisateur peut suivre le guide et comprendre si l’exemple a réussi.

Rédigé par le modèle d'indexation à partir du texte de l'issue.