Address docs TODOs

[Clay-Mysten]

This bug will capture open TODOs from the docs.

From our central README:
*To understand what's possible by browsing examples of full-fledged applications and games built on top of Sui, review the Demos

• To experience Sui's speed and scalability for yourself, try Benchmarking.--->
• To see the current status of the Sui software/network and preview what's coming next, read through our Roadmap.

Move quick start

Then deeper: Sui standard library, design patterns, examples.

Wallet quick start

Then deeper: wallet CLI vs client service vs forwarder architecture, how to integrate your code (wallet, indexer, ...) with the client service or forwarder components.

[Clay-Mysten]

Next, see Francois's comments in:
#693

[Clay-Mysten]

Another set of TODOs, from our Contributing page, currently at the following addess but moving to doc/src/contribute/index.md:
https://github.com/MystenLabs/sui/blob/main/CONTRIBUTING.md

TODO: Define basic system requirements for a reliable environment: recommended OS and required packages.

TODO: Note the git clone command above may fail with the following error, which should go away when we open our repo up:

TODO: Add links to the (Pull requests) steps above for more details, such as how to build and test the dev site and where to find the CLA once we have one.

[Clay-Mysten]

From:
https://github.com/MystenLabs/sui/main/doc/src/build/authorities.md

Pulled these TODO links:
sharded
read
clients
See Governance, Incentives, and Rewards for more detail.
reconfiguration
transaction validity checks
certificate validity checks
abort
inter-authority state sync
client-assisted state sync
EDITORIAL NOTE: not sure if the fixed duration part matches our plans--let me know
EDITORIAL NOTE: someone with BFT chops please correct/expand on this. Also confirm the <2/3 reference above is correct.
EDITORIAL NOTE: A diagram would be useful here.
TODO: Clarify the final clause (in the Transactions section) with an explanation of why the provider must not be trusted for safety.
EDITORIAL NOTE: please check that my advice about how many authorities a client should broadcast certs to looks good.

[Clay-Mysten]

From:
https://github.com/MystenLabs/sui/blob/main/doc/src/build/objects.md

EDITORIAL NOTE: A diagram would be useful here. Can we use Mermaid as now seen in the Summary thanks to Evan? Tracked in:
#564

EDITORIAL NOTE: Should we describe how to audit this here? In a separate section?

[Clay-Mysten]

From:
https://github.com/MystenLabs/sui/edit/main/doc/src/build/sui-json.md

TODO: Explain how this page will be used and by whom.
TODO: Complete invalid example.
For practical examples, see Anatomy Of A Move Call From REST & CLI
TODO: Fix Anatomy link above.

[Clay-Mysten]

From:
https://github.com/MystenLabs/sui/edit/main/doc/src/build/transactions.md

TODO: Define Gas and settle upon spelling and capitalization right here. And fix all broken links here.
-see Epochs.
--(see Addresses and Authenticators for more details).
entrypoint
verified
linked
initializer function
abort

EDITORIAL NOTE: today's transfer sends the input object instead of debiting it + creating/transferring a new object. But that seems inconvenient because a user will not typically have an object with exactly the intended value. This means the typical "send money" flow will be two txes: (1) split an existing coin object to get a fresh one with the desired value, then (2) send the fresh coin. I think we should change transfer to work in the way described here, which combines this into a single transaction. I think we will still want a transfer that works like the current one as well, but I think it should operate on (e.g.) nonfungible token types instead once we have a standard for those, and should support sending multiple tokens to multiple recipients in a single transaction.

EDITORIAL NOTE: this does not exist yet, but I think it should

TODO: Either add to the list of one above or combine with the intro sentence as one paragraph (includes Inputs...).

[Clay-Mysten]

In About Sui, Evan expressed concern about claims made. See:
#757

[Clay-Mysten]

Alberto rightfully suggests we develop some diagrams to depict our user flow from sender through certificate, both common and advanced, in How Sui Works.

[Clay-Mysten]

Arun, Adam, Sam and others have valuable input in the original REST Server doc we should consider for improvement:
#881

[Clay-Mysten]

From:
https://github.com/MystenLabs/sui/blob/explorer-rest/explorer/README.md

TODO: Link to guidance for how we want this done. Something generic resembling:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html

TODO: Find out if we need the "%2F" URL at the end. Also, can we include the URL without character substitution?

TODO: Remove or populate the "no more about running locally" header.

[Clay-Mysten]

From:
https://github.com/MystenLabs/sui/tree/explorer-rest/explorer/client

TODO: Explain the purpose of the client and relationship to the Sui Explorer described in the following page, linking between the two at the top:
https://github.com/MystenLabs/sui/blob/explorer-rest/explorer/README.md

TODO: Make link to this section: Please consult section Serving Apps with Client-Side Routing.

[Clay-Mysten]

From:
https://docs.sui.io/contribute/observability

TODO: see if keys need to be scoped by contexts

Observability of MOVE programs, events, etc.
TODO.

We need to provide means to authenticate the events etc (by linking them to signed effects).

TODO: Add instructions for setting env var and building Sui specially to enable Tokio-console support.