Edit, Complete and Refactor Documentation according to 3 "user stories"

[huitseeker]

Centralize and deploy light client documentation.

We would like the LC documentation & spec to

Places where some documentation can be found today:

• https://hackmd.io/aV22kOagT9Sx1ZHcsJnSIg (untagged!)
• https://hackmd.io/RQWc9TLVTjioP2NRHDfdug
• https://hackmd.io/fn1KsCngReW5P9hePh-vng
• https://www.notion.so/lurk-lab/Sphinx-Benchmarking-Guide-c17606bcaf4c4fc3a6537d502cbb3f95#97ebd7a079164beeb74bdf9c30354cdd
• https://github.com/lurk-lab/zk-light-clients/tree/main/aptos
• https://github.com/lurk-lab/zk-light-clients/tree/main/aptos/proof-server
• https://github.com/lurk-lab/zk-light-clients/tree/main/aptos/core

I expect that our audience, depending on their exact nature, will require three different documents:

1. as a Wormhole developer looking to productionize the LC, I will want to read an intro to the Aptos LC protocol, and an overview of the software package in the release,
2. as an auditor, I will want to read a light client spec, and link to the chips added by the Lurk team to Sphinx,
3. as a Wormhole Foudnation performance engineer, vetting the grant completion, I will want a specific process described with exacting precision of :
   • how to reproduce the benchmarking process (i.e. measuring the epoch change + block header verif e2e proof generation, and generating a number in seconds equal to the smaller of the two), described with exacting precision (including hardware, env variables, compiler options, the whole 9 yards),
   • a description of the reasoning behind this, including a link to the "client" program that runs parallel generation of block header and epoch change proof, justifying how the above "e2e latency" number adequately deals with the worst case scenario.

The entry point of our doc should be an "orientation" doc that dispatches the reader among the above 3 use cases. This "orientation" doc should be indiscutably easy to find and hard to miss.

[huitseeker]

My personal opinion is we can split two problems here:

• having a source of truth for the doc in the repo at each release (which shows that the doc exists, is up to date and is complete, but may not offer a great way to consult/read that doc),
• displaying that doc in a convenient location (which is solved at various degrees by a rust-book published to github pages, rustdoc published to GH pages, Notion, HackMD, etc).

In this issue we want to solve the first problem, and once it is solved, we have time to discuss how we deal with the second problem (doc display). IOW the MVP task here is making sure everything has a git source of truth that makes sense (possibly in Rust-book rather than "just" Readmes).