Consolidate Infura and custom network clients

Today we have two types of networks in the network controller: built-in Infura networks, and networks that we keep track of with the `networkConfigurations` state ("RPC" type networks). We also have two separate kinds of network clients with different middleware for each type of network and different network configuration objects. This leads to much unnecessary complexity.

We should only ever have to use one function to create a network client, and it should take the same shape for the network configuration, whether the network is an Infura network or custom network. This would greatly simplify the network controller API, and it would allow easier customization of which networks are built-in.

To achieve this, it is worth it to review the list of features that Infura network clients have over custom network clients:

- Custom retry error handling
The Infura networks use custom middleware that looks for Infura-specific errors, enabling more effective retry logic for Infura.
- Country blocked error handling
The Infura networks have custom support for an error that indicates geoblocking. This isn't supported for other networks.
- Secrets in RPC URLs
The Infura RPC URL we use has a secret embedded in the URL path. Our network configuration offers no way to obscure secrets in URL paths.
- Custom headers
We set custom fetch headers on requests to the built-in Infura networks.

Ideally, if we can enable these features for all networks, not just Infura ones, that would be ideal. However, if we need a way to customize a network client, then we should add new options to the network client configuration object which would allow for turning on select features.

Start by reviewing the network controller, the two network client paths, and their network configuration objects. Compare the listed Infura-specific retry handling, country-blocked errors, RPC URL secrets, and custom headers, then define a unified client creation shape that preserves or selectively configures these features; done means both built-in and custom networks use that single API.

Written by the indexing model from the issue text.