L1sload new design

[NazariiDenha]

1. Purpose or design rationale of this PR

Change behavior of l1sload precompile to new design

1. removed block number
2. allow multiple storage keys in a single call

To request multiple storage keys in a single call make batch RPC request

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• [ ] build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
• [ ] ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
• [ ] docs: Documentation-only changes
• [ ] feat: A new feature
• [ ] fix: A bug fix
• [ ] perf: A code change that improves performance
• [ ] refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
• [ ] style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• [ ] test: Adding missing tests or correcting existing tests

3. Deployment tag versioning

Has the version in params/version.go been updated?

• [ ] This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
• [ ] Yes

4. Breaking change label

Does this PR have the breaking-change label?

• [ ] This PR is not a breaking change
• [ ] Yes

[Turupawn]

Thanks for adding this :pray: Querying multiple slots at once can help saving gas and also offer good DevEx. I have a couple of questions:

1. The slots being queried have to been contiguous, all next to each other? Or can they be separate?
2. The max number of slots queried is 5 right? So 160 bytes.
3. Why did we decide to remove the block number? Is this to make it simpler, save gas or to reduce load on the scroll nodes? Nothing on top of my mind but I just wonder if we'll leave some use cases behind by doping historic data query

[NazariiDenha]

1. no, they shouldn't be contiguous, they can be separate
2. yes, for now it's 5. I implemented it following this doc https://github.com/ethereum/RIPs/pull/27. But it can be changed later
3. If I remember correctly, Haichen mentioned at the protocol meeting that the developers gave feedback that it was not necessary to have block number