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.

Inizia da README.md, in particolare dalle sezioni Step-by-Step Guide, Configure Your AVS e Simulate Task Execution, quindi esamina l’esempio main.go predefinito e l’entry point della chiamata avs del devkit. Chiarisci il flusso di quickstart, i requisiti di configurazione e RPC, gli argomenti dei comandi, il contesto di TaskMailbox e come gli utenti possono verificare la ricezione dell’attività. Il lavoro è completato quando un nuovo utente può seguire la guida e capire se l’esempio ha avuto successo.

Scritto dal modello di indicizzazione a partire dal testo della issue.