PyMemoryView_FromMemory is part of stable ABI but the flag constants
such as PyBUF_READ are not. This was fixed in Python 3.11 [1], but still
requires this workaround when using older versions.

[1] https://github.com/python/cpython/issues/98680

This adds a CMake option (which defaults to OFF) to force building
against the Python limited API. This makes iterating on #151617 easier
and eventually will prevent us from regressing this configuration.

As decided on
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731.

LLDB 20 recommended `>= 3.8` but did not remove support for anything
earlier. Now we are in what will become LLDB 21, so I'm removing that
support and making
`>= 3.8` required.

See https://docs.python.org/3/c-api/apiabiversion.html#c.PY_VERSION_HEX
for the format of PY_VERSION_HEX.

Use PY_VERSION_HEX to simplify conditional compilation depending on the
Python version.

This also adds a static_assert to lldb-python to error out with a
meaningful diagnostic when you try building LLDB with an older Python
version in preparation for [1].

[1]
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731/15

```
lldb-python.h:16:30: warning: ‘g_fcxx_modules_workaround’ defined but not used [-Wunused-variable]
   16 | static llvm::Expected<bool> *g_fcxx_modules_workaround;
      |
```

Workaround originally added in 36cb29cbbe1b22dcd298ad65e1fabe899b7d7249.

This patch works around what looks like a bug in Clang itself.

The error on the bot is:

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/40466/consoleText

In module 'LLVM_Utils' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h:18:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: error: 'llvm::Expected<bool>::(anonymous)' from module 'LLVM_Utils.Support.Error' is not present in definition of 'llvm::Expected<bool>' in module 'LLVM_Utils.Support.Error'
  union {
  ^
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: note: declaration of '' does not match
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: note: declaration of '' does not match
1 error generated.

The intention is to revert this as soon as a proper fix has been identified!

rdar://87845391

This matches the naming scheme used by LLVM and all the other optional
dependencies in LLDB.

Differential revision: https://reviews.llvm.org/D71482

As suggested by Pavel in a code review:

> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..

Differential revision: https://reviews.llvm.org/D71280

This patch limits the scope of the python header to the implementation
of the python script interpreter plugin. ScriptInterpreterPython is now
an abstract interface that doesn't expose any Python specific types, and
is implemented by the ScriptInterpreterPythonImpl.

Differential revision: https://reviews.llvm.org/D59976

llvm-svn: 357307

to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636