feat(share/getters): Implement a peer routing solution based on request

[renaynay]

Problem

#3188 introduces a complexity into the design of shrex getter where it now has to take an additional archival peer manager and perform a check in shrex.go on each request whether the timestamp of the header is historic or not, and route accordingly.

This is ugly and does not scale with other types of routing that could be required in the future with the introduction of partial nodes, for example, where requests could be routed to peers serving historic data for a specific namespace.

Ideas for solution

A PeerGetter function / component that can be mounted on the shrex getter that will fetch the best peer (or best few peers) that would be able to respond to the request.

This can be generalised to handle the following:

• whether request is recent or historic
• based on whether it's a request for ND and if the node is running a disc + peerMan for that namespace, among other potential use cases that we haven't yet defined

[walldiss]

The original suggestion was to move routing logic to Getter instead of peers.Manager. The main difference is that Getter is aware of header, while peer.Manager does not. I'm against putting more logic into peer.Manager, as it is already quite complex and routing logic can be extracted to be implemented fully externally.
Full description: https://github.com/celestiaorg/celestia-node/pull/3188#issuecomment-2104661328