Create useful documentation for end users

[lidel]

Problem

Users of ipfs-http-client from js-ipfs have docs like this: https://github.com/ipfs/js-ipfs/blob/master/docs/core-api/FILES.md

Users of kubo-rpc-client have no such resource.
Automatically generated docs only describe constructor

Solution

TBD.

Can we leverage TS to generate docs for every command?
Improve preexisting https://ipfs.github.io/js-kubo-rpc-client/?

[BigLep]

As part of this, lets please do a clean up on https://github.com/ipfs/js-kubo-rpc-client/blob/master/README.md

We have statements like

This client is still a work in progress and in active development. Please refer to ipfs-http-client for now and only use this package if you are aware of the implications. Follow https://github.com/ipfs/js-kubo-rpc-client/milestone/1 for tracking when this library is ready for consumption

which I don't think are accurate

[hacdias]

@lidel @BigLep I think we should go for a multi-phase plan:

1. Generate the documentation based on interface-ipfs-core, since we are still importing those types.
2. Decouple js-kubo-rpc-client from ìnterface-ipfs-core` by either (a) copy-pasting the types here, or (b) rewrite in TypeScript. Then, generate the documentation based on that. Notes:
   a. This will make us have to maintain both types and implementation separately. Essentially there would be a 1:1 file match for every types : implementation.
   b. This will take longer initially, but then we only need to maintain the client as it is and the types would automatically be connected to the implementation.

Please note that after decoupling, we should remove methods that are not present in Kubo, as well as options, which will likely break https://github.com/ipfs/interop.

[hacdias]

Just want to give an update here: both interface-ipfs-core and interop have been deprecated and archived. Therefore, the plan above no longer applies.