Add raise_on_error=False option to batched request execution

[genisis0x]

Summary

Today a single failing request in a batch propagates a `Web3RPCError` out of `RequestBatcher.execute` / `async_execute`, discarding every sibling response even when those came back successfully. That's painful for callers (relayers, indexers, multi-call aggregators) where partial results are more useful than total failure.

Add a `raise_on_error` keyword (default `True`, preserving current behavior) on both batch execute entry points. When set to `False`, the manager-level batch dispatcher skips the per-request raise inside `_format_batched_response` and returns the raw RPC response dict for failing entries — successful entries are still passed through the result formatters. Envelope-level errors (server returned a single error object instead of an array) still raise.

Persistent-connection providers always raise at the socket layer today, so `raise_on_error` is only honored for stateless (HTTP) providers in this PR. The async-socket path can adopt the same flag in a follow-up once the socket-side response routing is opted-in to the flag.

Closes #3657

Test plan

• Added `test_http_batch_request_raise_on_error_false_returns_per_request_errors` covering a mocked 2-entry batch where the first response carries an error and the second a result. Asserts:
  • the failing entry is returned with `response["error"]["message"] == "bad request"`,
  • the successful entry is still formatted to the expected type,
  • `provider._is_batching` is reset.
• Existing `test_http_empty_batch_response` confirms envelope-level errors still raise.