getLogs improvements

Using `eth_getLogs` for indexing is very painful.

1. there is no built in reorg handling
2. there is no consistent error on exceeded range https://github.com/ponder-sh/ponder/blob/ba9a1b5e1262efe0dc7341de7f600ed32d52b391/packages/utils/src/getLogsRetryHelper.ts#L36 and no consistent limits accross providers
3. there is no [pagination](https://github.com/ethereum/execution-apis/issues/617)
4. json rpc is not very efficient
5. when fetching up to `latest`, you do not know what `latest` was - just which was the last block that contained an event

While 3),4) and 5) probably cannot be solved within the existing spec, i guess the other two perhaps could be?

For 1) `fromBlock` could potentially accept a blockHash or a new `fromBlockHash` could be introduced.
Not entirely sure what should happen when `fromBlockHash` is orphaned though - opening this issue to start the discussion.

For 2) i guess it's a pure matter of standardizing the error.

---

I've worked a lot with rpcs and other data providers over the years and for what it's worth [envio](https://docs.envio.dev/docs/HyperSync/hypersync-query#query-structure-reference) has managed to come up with a api that reliably solves these issues. Wondering if we could have a more sophisticated (envio like)api on the clients.

Start with the eth_getLogs behavior described here and the linked execution-apis pagination issue; compare the reorg and error-standardization questions with the referenced getLogsRetryHelper.ts and Envio query structure. Done means the API or spec scope and semantics are agreed and the affected execution-apis entry points are identified.

Written by the indexing model from the issue text.