Add a "Using LLDB" section to the welcome page of the website

[aprantl]

Summary

This is an attempt to feature the user-facing resources more prominently on the LLDB website by calling out the tutorial and the GDB command map wight on the start page.

I also moved the "Why a new debugger" section to the "Goals" subpage. Given that LLDB's first release is almost a decade in the past now, the title is a bit of an anachronism.

Lastly, I moved the Architecture sub-page from "use" to "resources", since end-users do not care about the source code layout.

[JDevlieghere]

Please add a redirect in the .htaccess file for the architecture page.

[labath]

Sounds like a good idea.

[shafik]

lldb/docs/index.rst

25

other debuggers -> GDB?

28

Pythonl -> Python

29

staring -> starting

lldb/docs/status/goals.rst

38

Is it worth adding anything about expression parsing here as well?

[aprantl]

Cool, I didn't know about the redirects!

[aprantl]

lldb/docs/status/goals.rst

38

Perhaps :-)
I'll consider that out of scope for this patch though.

[JDevlieghere]

LGTM with the comment.

lldb/docs/.htaccess

3

Can you move this line down under Sphinx redirects? I'm trying to keep old redirects (from the html website) separate from reorgs in the sphix docs.

lldb/docs/.htaccess

-Redirect 301 /architecture/index.html https://lldb.llvm.org/use/architecture.html
+Redirect 301 /architecture/index.html https://lldb.llvm.org/resources/architecture.html
 Redirect 301 /cpp_reference/html/index.html https://lldb.llvm.org/cpp_reference/index.html
 Redirect 301 /features.html https://lldb.llvm.org/status/features.html
 Redirect 301 /formats.html https://lldb.llvm.org/use/formatting.html
 Redirect 301 /goals.html https://lldb.llvm.org/status/goals.html
 Redirect 301 /lldb-gdb.html https://lldb.llvm.org/use/map.html
 Redirect 301 /projects.html https://lldb.llvm.org/status/projects.html
 Redirect 301 /remote.html https://lldb.llvm.org/use/remote.html
 Redirect 301 /source.html https://lldb.llvm.org/resources/contributing.html
 Redirect 301 /tutorial.html https://lldb.llvm.org/use/tutorial.html
 Redirect 301 /varformats.html https://lldb.llvm.org/use/variable.html
 
 # Sphinx redirects
 Redirect 301 /resources/source.html https://lldb.llvm.org/resources/contributing.html
 Redirect 301 /resources/download.html https://lldb.llvm.org/status/releases.html
+Redirect 301 /use/architecture.html https://lldb.llvm.org/resources/architecture.html

lldb/docs/index.rst

 LLDB is the default debugger in Xcode on macOS and supports debugging C,
 Objective-C and C++ on the desktop and iOS devices and simulator.
 
 All of the code in the LLDB project is available under the
 `"Apache 2.0 License with LLVM exceptions"`_.
 
 .. _"Apache 2.0 License with LLVM exceptions": https://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework
 
-Why a New Debugger?
--------------------
+Using LLDB
+----------
 
-In order to achieve our goals we decided to start with a fresh architecture
-that would support modern multi-threaded programs, handle debugging symbols in
-an efficient manner, use compiler based code knowledge and have plug-in support
-for functionality and extensions. Additionally we want the debugger
-capabilities to be available to other analysis tools, be they scripts or
-compiled programs, without requiring them to be GPL.
+For an introduction into the LLDB command language, head over to the
+:ref:`LLDB Tutorial <use/tutorial>`. For users already familiar with
+GDB there is a cheat sheet listing common tasks and their LLDB
+equivalent in the :ref:`GDB to LLDB command map <use/map>`.
+
+There are also multiple resources on how to script LLDB using Python
+:ref:`Python Reference <use/python-reference>` is a great starting
+point for that.
 
 Compiler Integration Benefits
 -----------------------------
 
-LLDB currently converts debug information into clang types so that it can
-leverage the clang compiler infrastructure. This allows LLDB to support the
+LLDB converts debug information into Clang types so that it can
+leverage the Clang compiler infrastructure. This allows LLDB to support the
 latest C, C++, Objective-C and Objective-C++ language features and runtimes in
 expressions without having to reimplement any of this functionality. It also
 leverages the compiler to take care of all ABI details when making functions
 calls for expressions, when disassembling instructions and extracting
 instruction details, and much more.
 
 The major benefits include:
 
 - Up to date language support for C, C++, Objective-C
 - Multi-line expressions that can declare local variables and types
 - Utilize the JIT for expressions when supported
 - Evaluate expression Intermediate Representation (IR) when JIT can't be used
 
 Reusability
 -----------
 
 The LLDB debugger APIs are exposed as a C++ object oriented interface in a
 shared library. The lldb command line tool links to, and uses this public API.
 On macOS the shared library is exposed as a framework named LLDB.framework,
-and unix systems expose it as lldb.so. The entire API is also then exposed
+and Unix systems expose it as lldb.so. The entire API is also then exposed
 through Python script bindings which allow the API to be used within the LLDB
 embedded script interpreter, and also in any python script that loads the
 lldb.py module in standard python script files. See the Python Reference page
 for more details on how and where Python can be used with the LLDB API.
 
 Sharing the LLDB API allows LLDB to not only be used for debugging, but also
 for symbolication, disassembly, object and symbol file introspection, and much
 more.
 
 Platform Support
 ----------------
 
 LLDB is known to work on the following platforms, but ports to new platforms
 are welcome:
 
 * macOS desktop user space debugging for i386 and x86_64
-* iOS simulator debugging on i386 and x86_64
-* iOS device debugging on ARM and AArch64
+* iOS, tvOS, and watchOS simulator debugging on i386 and x86_64
+* iOS, tvOS, and watchOS device debugging on ARM and AArch64
 * Linux local user-space debugging for i386, x86_64 and PPC64le
 * FreeBSD local user-space debugging for i386 and x86_64
 * Windows local user-space debugging for i386 (*)
 
 (*) Support for Windows is under active development. Basic functionality is
 expected to work, with functionality improving rapidly.
 
 Get Involved
 ------------
 
 Check out the LLVM source-tree with git and find the sources in the `lldb`
 subdirectory:
 
 ::
 
   > git clone https://github.com/llvm/llvm-project.git
 
 Note that LLDB generally builds from top-of-trunk using CMake and Ninja.
 Additionally it builds:
 
 * on macOS with a :ref:`generated Xcode project <CMakeGeneratedXcodeProject>`
-* on Linux and FreeBSD with clang and libstdc++/libc++
-* on NetBSD with GCC/clang and libstdc++/libc++
+* on Linux and FreeBSD with Clang and libstdc++/libc++
+* on NetBSD with GCC/Clang and libstdc++/libc++
 * on Windows with a generated project for VS 2017 or higher
 
 See the :doc:`LLDB Build Page <resources/build>` for build instructions.
 
 Discussions about LLDB should go to the `lldb-dev
 <http://lists.llvm.org/mailman/listinfo/lldb-dev>`__ mailing list. Commit
 messages are automatically sent to the `lldb-commits
 <http://lists.llvm.org/mailman/listinfo/lldb-commits>`__ mailing list , and
.. toctree::
    use/formatting
    use/variable
    use/symbolication
    use/symbols
    use/python
    use/python-reference
    use/remote
    use/troubleshooting
-   use/architecture
 
 .. toctree::
    :hidden:
    :maxdepth: 1
    :caption: Development
 
+   resources/architecture
    resources/contributing
    resources/build
    resources/test
    resources/bots
    resources/reproducers
    resources/sbapi
    resources/caveats
 

lldb/docs/status/goals.rst

* Build libraries for inclusion in IDEs, command line tools, and other analysis
   tools
 * High performance and efficient memory use
 * Extensible: Python scriptable and use a plug-in architecture
 * Reuse existing compiler technology where it makes sense
 * Excellent multi-threaded debugging support
 * Great support for C, Objective-C and C++
 * Retargetable to support multiple platforms
 * Provide a base for debugger research and other innovation
+
+Why a New Debugger?
+-------------------
+
+In order to achieve our goals we decided to start with a fresh architecture
+that would support modern multi-threaded programs, handle debugging symbols in
+an efficient manner, use compiler based code knowledge and have plug-in support
+for functionality and extensions. Additionally we want the debugger
+capabilities to be available to other analysis tools, be they scripts or
+compiled programs, without requiring them to be GPL.
+