Develop plan for metrics on the utility/impact of boxo

## Done Criteria
There is a credible plan for how we'd measure the utility and impact of go-libipfs, especially compared to the previous status quo of many smaller repos

## Why Important
This endeavor of consolidating repos (https://github.com/ipfs/go-libipfs/issues/196 ) is not free by any means. @ipfs/kubo-maintainers hypothesize it will:
1. Make it easier for users to create tailored IPFS solutions because there is a set of dependencies that all work together with working examples.
2. Reduce maintenance burden for maintainers because they can make important refactors that have been cost-prohibitive in the past due to the repo sprawl

This should be verified.

## Notes
The work of setting these metrics up will likely occur in other issues.

At the minimum, metrics that we'd want to see as a result of this:
1. Number and derivative of dependent projects on go-libipfs vs. the set of ipfs/go-* repos that have been copied in.
2. Number and derivative of meaningful contributors to go-libipfs vs. the set of ipfs/go-* repos that have been copied in.
3. Issue / PR response and resolution times in go-libipfs vs. the set of ipfs/go-* repos that have been copied in
4. Reduction in average time for a PR to be merged.
5. Increase in release cycle frequency.
6. Code coverage % increase

The ipfs/ecoystem-dashboard will likely be relevant here.