Initial split of get started -> local into user guides

[morgo]

This is a documentation refactor. Let me explain the motivations:

• The current user-guides are not very task-oriented (Improve User Guides #263). User guide should mean "here is a set of steps to achieve a specific goal".
• Part of this is due to the use of shell scripts like ./301_customer_sharded.sh. i.e. there is no expressive API that is truly universal (context is key, including working directory). We should be making this script obsolete. i.e. instead of:

set -e

./lvtctl.sh ApplySchema -sql-file create_commerce_seq.sql commerce
./lvtctl.sh ApplyVSchema -vschema_file vschema_commerce_seq.json commerce
./lvtctl.sh ApplySchema -sql-file create_customer_sharded.sql customer
./lvtctl.sh ApplyVSchema -vschema_file vschema_customer_sharded.json customer

disown -a

.. we make sure that vtctlclient accepts a config file (issue vitessio/vitess#4921) and replace the script with a manual page that shows a solution that works for all deployment methods:

vtctlclient ApplySchema -sql-file create_commerce_seq.sql commerce
vtctlclient ApplyVSchema -vschema_file vschema_commerce_seq.json commerce

vtctlclient ApplySchema -sql-file create_customer_sharded.sql customer
vtctlclient ApplyVSchema -vschema_file vschema_customer_sharded.json customer

If we do this, the examples also become more portable.. since I can figure out how to apply them to my use case without copying the whole examples directory.

---

So now to describe what is changed here:

• The local guide only covers deployment, and then suggests a next step.
• The next step of Vertical split uses MySQL from a global location (because the local guide showed how to setup mysql cli config).
• The user guides for vertical split and horizontal split are closer to deployment scenario agnostic (closer but not there yet. The goal should be that one could go from the Kubernetes or Vagrant deploy guide straight to here too, with one version to maintain.)

Also:
Fixes #298
Fixes #315

Long term this will also lead to less duplicate content, since there is overlap between kubernetes and local. It will also make it easier to add deploy guides for every cloud deployment scenario separately (GKE, EKS, Azure, etc.) without the duplicate content.

[sougou]

Some thoughts and comments:

• A downside of this approach is that the storyline gets lost. If someone starts off with "Getting Started", they can get lucky and follow the full story. But someone directly jumping into horizontal resharding may find it confusing. I don't have a better alternative yet though.

• 401_teardown.sh doesn't clean up everything. Some of the cleanup is done by 206_clean_commerce.sh. We need to address that part.

• I like the mysql launch improvement. We should definitely do the same thing for vtctlclient.

[morgo]

• A downside of this approach is that the storyline gets lost. If someone starts off with "Getting Started", they can get lucky and follow the full story. But someone directly jumping into horizontal resharding may find it confusing. I don't have a better alternative yet though.

I did put an Info tag to suggest using vertical first, but there could be some troubleshooting, because it will get ignored based on this pattern.

• 401_teardown.sh doesn't clean up everything. Some of the cleanup is done by 206_clean_commerce.sh. We need to address that part.

I can fix this in code. I will modify 401 to also do 206_'s work if required.

• I like the mysql launch improvement. We should definitely do the same thing for vtctlclient.

[morgo]

@sougou 401_teardown can now start from any point. Do you have any issues if we merge this PR?