This patch adds the notion of "Facade" locations which can be reported
from a ScriptedResolver instead of the actual underlying breakpoint
location for the breakpoint. Also add a "was_hit" method to the scripted
resolver that allows the breakpoint to say which of these "Facade"
locations was hit, and "get_location_description" to provide a
description for the facade locations.

I apologize in advance for the size of the patch. Almost all of what's
here was necessary to (a) make the feature testable and (b) not break
any of the current behavior.

The motivation for this feature is given in the "Providing Facade
Locations" section that I added to the python-reference.rst so I won't
repeat it here.

rdar://152112327

This pages improve the LLDB website documentation readability and
discoverability by breaking down the very long python-reference page
into multiple subpages each explaining a specific topic.

The long term goal is to have tutorials for every scripting extension.

This also converts the pages to markdown, since it's easier to write.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

The examples on this page were using the Python 2-style print. I ran the
updated code examples under Python 3 to confirm they are still
up-to-date.

If your arguments or option values are of a type that naturally uses one
of our common completion mechanisms, you will get completion for free.
But if you have your own custom values or if you want to do fancy things
like have `break set -s foo.dylib -n ba<TAB>` only complete on symbols
in foo.dylib, you can use this new mechanism to achieve that.

The API is present, and we even have a test for it, but it isn't
documented so no one probably knows you can set requirements for your
scripted commands. This just adds docs and uses it appropriately in the
`framestats` example command.

Among other things, returning an empty string as the repeat command
disables auto-repeat, which can be useful for state-changing commands.

There's one remaining refinement to this setup, which is that for parsed
script commands, it should be possible to change an option value, or add
a new option value that wasn't originally specified, then ask lldb "make
this back into a command string". That would make doing fancy things
with repeat commands easier.

That capability isn't present in the lldb_private side either, however.
So that's for a next iteration.

I haven't added this to the docs on adding commands yet. I wanted to
make sure this was an acceptable approach before I spend the time to do
that.

This has been available for years now, so it should be safe to always
use it.