bitswap/server: allow overriding peer ledger with WithPeerLedger

[hacdias]

Introduces WithPeerLedger, which allows to override the default peer ledger with anything else you want.

[codecov]

Codecov Report

Attention: Patch coverage is 63.33333% with 11 lines in your changes are missing coverage. Please review.

Project coverage is 59.69%. Comparing base (eeea414) to head (8d74823).

@@            Coverage Diff             @@
##             main     #607      +/-   ##
==========================================
- Coverage   59.88%   59.69%   -0.20%     
==========================================
  Files         238      238              
  Lines       29868    29883      +15     
==========================================
- Hits        17887    17839      -48     
- Misses      10375    10425      +50     
- Partials     1606     1619      +13     

Files	Coverage Δ
bitswap/server/internal/decision/peer_ledger.go	94.17% <100.00%> (-1.79%)	⬇️
bitswap/options.go	38.09% <0.00%> (-1.91%)	⬇️
bitswap/server/internal/decision/engine.go	91.22% <20.00%> (-0.68%)	⬇️
bitswap/server/server.go	64.63% <0.00%> (-2.43%)	⬇️

... and 16 files with indirect coverage changes

[lidel]

I don't feel strongly how we name it, but

• feels like we could go away with adding just one option for this
• rainbow should use explicit noopPeerLedger that has all methods implemented as noop. this will be less prone to breakage / bugs during refactors.

details inline

[hacdias]

@lidel I refactored to only have one new option (WithPeerLedger). I did not add a no-op peer ledger here. I will do this in Rainbow. My idea is that I didn't want to export custom peer ledgers here. We also do not export the default peer ledger, just like it has been done with the score ledger. Just trying to avoid inconsistencies here. If we want to use the no-op peer ledger in other places, we can then bring it to Boxo.

[lidel]

Lgtm, follows what we already had for WithScoreLedger and does not introduce anything new.

---

Digression on future work:
We are still figuring out what appropriate settings for rainbow are, but once we do, it will be useful for others. If we want to add a higher abstraction similar to what @aschmahmann suggested (WithRequestResponseOnly), I feel it needs to be more generic, e.g.: WithProfile("minimal-request-response") because it would adjust multiple settings, and work similar to Kubo profiles.