feat: refactor ICQ module documentation [NTRN-349]

[sotnikov-s]

task

https://hadronlabs.atlassian.net/browse/NTRN-349

this PR

Redesigns the interchainqueries module documentation by applying the docs design technique described here https://docs.divio.com/documentation-system:

• simplifies the Overview section by giving only a high level definition to the reader and by moving several topics from the Overview section to Explanation, How To and Known bugs sections;
• introduces the Explanation section that contains detailed description of various concepts and design decisions of the module;
• introduces the How To section that contains step-by-step instructions on typical user actions;
• introduces the API section that describes the module's interface;
• introduces the Known bugs section that lists currently known issues and possible workarounds related to the module;

related PRs

• feat: refactor ICQ module documentation [NTRN-349] neutron#646

notes

• since the PR is still is a draft, there are possible misprints and text format inconsistencies. If you spotted one, please don't hesitate to leave a comment even if it's a little mistake;
• please think hard about additional topics that should be covered in the How To and Explanation sections;
• the How To section is very unpolished, yet. More info about the work required to be done on that sections is in the before the merge section of the PR description;
• I'd really appreciate any feedback on the PR.

left to be done

• write the How to register a TX-typed Interchain Query with custom keys instruction in the How To section;
• questionable: find a way to replace go.doc links to request/response models with links to proto documentation. Motivation: go doc is golang specific whereas proto documentation is more generic;
• regarding this concern about documentation quality: I want to add a couple of contracts that will be the origin of the code attached to the How To section instructions, and add integration tests for these contracts. This would 1) make us assured of the code snippets from the How To section, because the code will be taken from a real contract, not from the top of our heads; 2) make us assured that the contract and the instructions work in time; 3) highlight by failing tests any changes required to be done in the docs regarding the instructions.

before the merge

• check all links from the module docs manually;
• after the related PR to Neutron repo merge, check the links one more time to make sure the renamed types are linked correctly.

[joldie777]

Fix conflicts please