Stricter validation for JSON-RPC responses

[fselmo]

What was wrong?

Closes #3095 by more tightly validating the JSON-RPC responses coming from providers (not just the id as the issue states) while providing good messaging on errors.

This PR also includes the following changes:

• Use Web3RPCError instead of a generic Web3ValueError for JSON-RPC errors returned by the provider.
• Error log the user_message, debug log the response for RPC errors for better clarity / debugging.
• In the spirit of wrapping up breaking changes for v7 and snake-casing some final remnants of camelCase args, capitalize "Of": BlockNumberOutofRange -> BlockNumberOutOfRange
• Distinguish between MethodUnavailable (a JSON-RPC error from the node) and MethodNotSupported (web3.py does not support the method, internally, under some conditions).
• Re-organize the formatted_response tests to be more readable. Separate test cases into tests where they make sense together: test valid responses, test invalid fields, test valid error responses, test invalid error object, test error formatters and null formatters together.

How was it fixed?

Todo:

• Clean up commit history
• Add or update documentation related to these changes (including the v7 migration guide)
• Add entry to the release notes

Cute Animal Picture

[fselmo]

Note: This change is also breaking but this is how it should be defined. The only reason we allowed str is bc of how EthereumTesterProvider returned errors but that should not be allowed imo.

[pacrob]

lgtm!

[kclowes]

I like that BlockNumberOutOfRange change, nice! I left a comment around making sure we've tested against a range of providers to make sure it makes sense to validate the rpc response. (I have scarring from this chunk of code, lol) I also left a nit about importing merge from eth-utils instead of from toolz. But once those are addressed, this LGTM!