Standardize best practices for error handling in libraries

[mDuo13]

Our sample code should embody best practices around catching errors, even if all the sample code does after catching the error is just to print it and quit.

This can be tricky because the client libraries handle different types of errors differently:

• They throw an exception for some types of errors, like a network error or syntax/request formatting error.
• They return an unsuccessful response from the server, without throwing, for other types of errors like an entry or transaction not found in the ledger/history.
• They return a transaction that was validated with a tec code, meaning it probably did not accomplish its intended purpose, without throwing.

Also, I'm not sure that xrpl.js and xrpl-py are even consistent with each other in how they handle these cases, to say nothing of other client libraries.

Acceptance Criteria

Create a new document or section describes the best practices for handling, in both Python and JavaScript, the following error cases:

• API request failures in processing (like network errors).
• API responses that include an error from the server (like "not found" errors).
• Transaction results that aren't successful, when submitting transactions using a "submit and wait" function.
• Bonus points: using a "simple" transaction submit function that does not wait for a validated result. (For example, a response of terQUEUED indicates the transaction will likely become validated soon but is not a final result.

If possible: update sample code of relevant tutorials to embody the best practices.

[mDuo13]

Did a little bit of research and this is a place where xrpl.js and xrpl-py diverge. Made a request for xrpl-py to fix this, but it would be a breaking change: XRPLF/xrpl-py#893