`network-controller`: Capture whether a network is degraded as well as latency during `lookupNetwork`

## Problems

- Clients do not have an elegant way of listening for when a network is degraded during the connection phase.
- Clients have no way of knowing the latency of an RPC endpoint.

## Background

When loading the wallet or enabling a network on the client side, we would like to display a message if the network is degraded in some fashion (i.e., an initial request takes longer than 5 seconds to resolve, or there are 5 consecutive requests that do not resolve successfully).

While we could certainly subscribe to `NetworkController:rpcEndpointDegraded`, this event fires each time that NetworkController detects that an endpoint is degraded, and we are only interested in what happens initially.

Instead, it is typical that clients listen for changes in `networksMetadata`. This state property records information about all networks, and one piece of information is `status`, which represents the connectivity/availability status. Currently there are four possible values, `available`, `blocked`, `unavailable`, and `unknown`.

Beyond this need, we have a secondary need, which is that if the user has a bunch of custom RPC endpoints, we may want to display the latency for each endpoint so that they understand which ones are more available.

## Acceptance Criteria

- The `status` property in `networksMetadata` property has a new `degraded` status, which is set when the request to fetch the latest block takes longer than 5 seconds to resolve.
- `networksMetadata` has a new property, `latency`, which records the final time of the request to fetch the latest block.