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 ↗

(On Diff #230103)

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/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
+other debuggers there is also 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 Pythonl
+:ref:`Python Reference <use/python-reference>` is a great staring
+point for that.
 
 Compiler Integration Benefits
 -----------------------------
 
-LLDB currently converts debug information into clang types so that it can
+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:
.. 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.
+