docs: Add TSDoc comments to @libp2p/interface

[hthomp15]

docs: Add TSDoc comments to @libp2p/interface (#2112)

Description

This PR adds TSDoc comments to the public interfaces of @libp2p/interface, ensuring that the documentation is properly structured and generated using the @packageDocumentation tag.

Every exported interface, type, enum, and constant is documented according to the TSDoc standard.

Related issue: #2112

Notes & open questions

@maschad
I noticed that the original links in the issue no longer exist. Could you provide updated examples or confirm which specific files should be prioritized for these changes?

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[achingbrain]

The @libp2p/interface code can be found here: https://github.com/libp2p/js-libp2p/tree/main/packages/interface

I think one PR that adds comprehensive documentation for all exported members may be too big a chunk of work, you may wish to perform this task as several smaller PRs that change a handful of files/dirs at a time.

[hthomp15]

Sounds good @achingbrain. I can break this up into smaller PRs.

[hthomp15]

@achingbrain @maschad would love to get some feedback. I can make this PR with what I have so far.

[achingbrain]

Thanks for opening this. A lot of the comments here don't add much information that isn't obtainable from the types (e.g. field names/types) but it's better than what we have now.

Linting is failing in CI, can you please take a look?

The linting steps run in CI can be seen in main.yml.

You can fix all fixable linting issues by running

npm run lint -- -- --fix

..in the root of the repo, or

npm run lint -- --fix

..in each individual package.

[achingbrain]

I'm not convinced this style of comment gives the reader any useful information.

There are many examples of this in this PR, too many to comment on them each individually.

As a rule, if all the comment is doing is repeating the name or the type of the property it's better off not having a comment at all since it doesn't add any more information that what is contained in the interface/field name/type.