Block size limit: make configurable

### Checklist

- [X] My issue is specific & actionable.
- [X] I am not suggesting a protocol enhancement.
- [X] I have searched on the [issue tracker](https://github.com/ipfs/kubo/issues?q=is%3Aissue) for my issue.

### Description

This is a proposal to expose what is commonly known as the "block size limit" (which I think is actually the maximum number of bytes that can be read/written to a stream?), while keeping the default.

* There is no reason that private ipfs network adjust the limit to whatever they want. This should be easily configurable and not require re-compiling ipfs.
* I would argue, there is not reason that participants in the public ipfs network cannot decide to work with higher block limits (or smaller), based on their own needs.
* Useful feedback can be provided to the user in the form of "block-too-large" errors when adding or fetching large blocks.

Rationale: currently, users are able to adjust resource-manager settings that limit how many connections they accept or how much memory they use. I don't see this setting as anything different. We don't consider it an anomaly if we cannot talk to a peer because our connections get killed by the resource manager. We should not worry either that we cannot download a block because it is too big for the limit.

No files, tests, or entry points are named. Start by tracing the existing block-size limit and its add/fetch error paths, then define the configuration and default behavior. Done should include adjustable limits without recompilation and clear block-too-large feedback.

Written by the indexing model from the issue text.