Develop plan for metrics on the utility/impact of boxo

[BigLep]

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 (#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.