This fixes a data race between the main thread and the default event
handler thread. The statusline format option value was protected by a
mutex, but it was returned as a pointer, allowing one thread to access
it while another was modifying it.

Avoid the data race by returning format values by value instead of by
pointer.

Adds the new `plugin.cplusplus.display.function-name-format` setting and makes the `${function.name-with-args}` query it for formatting the function name.

One caveat is that the setting can't itself be set to `${function.name-with-args}` because that would cause infinite recursion and blow the stack. I added an XFAILed test-case for it and will address it in a follow-up patch.

https://github.com/llvm/llvm-project/pull/131836

Adds new frame-format variables and implements them in the CPlusPlusLanguage plugin.

We use the `DemangledNameInfo` type to retrieve the necessary part of the demangled name.

https://github.com/llvm/llvm-project/pull/131836

The original PR is #132274.

Co-authored-by: @bulbazord Alex Langford

Both the `CPlusPlusLanguage` plugins and the Swift language plugin
already assume the `sc != nullptr`. And all `FormatEntity` callsites of
`GetFunctionDisplayName` already check for nullptr before passing `sc`.
This patch makes this pre-condition explicit by changing the parameter
to `const SymbolContext &`. This will help with some upcoming changes in
this area.

Reverts llvm/llvm-project#132274

Broke a test on LLDB Widows on Arm:
https://lab.llvm.org/buildbot/#/builders/141/builds/7726
```
FAIL: test_dwarf (lldbsuite.test.lldbtest.TestExternCSymbols.test_dwarf)
<...>
    self.assertTrue(self.res.Succeeded(), msg + output)

AssertionError: False is not true : Command 'expression -- foo()' did not return successfully

Error output:

error: Couldn't look up symbols:

  int foo(void)

Hint: The expression tried to call a function that is not present in the target, perhaps because it was optimized out by the compiler.
```

This patch addresses the issue #129543.
After this patch the size of lldb-server is reduced by 9MB.

Co-authored-by: @bulbazord Alex Langford

## Description
This pull request adds a new `stop-at-user-entry` option to LLDB
`process launch` command, allowing users to launch a process and pause
execution at the entry point of the program (for C-based languages,
`main` function).

## Motivation
This option provides a convenient way to begin debugging a program by
launching it and breaking at the desired entry point.

## Changes Made
- Added `stop-at-user-entry` option to `Options.td` and the
corresponding case in `CommandOptionsProcessLaunch.cpp` (short option is
'm')
- Implemented `GetUserEntryPointName` method in the Language plugins
available at the moment.
- Declared the `CreateBreakpointAtUserEntry` method in the Target API.
- Create Shell test for the command
`command-process-launch-user-entry.test`.

## Usage
`process launch --stop-at-user-entry` or `process launch -m` launches
the process and pauses execution at the entry point of the program.

I don't think this needs to be a ConstString.

Differential Revision: https://reviews.llvm.org/D150709

Move responsibility of providing the instance variable name (`this`, `self`) from
`TypeSystem` to `Language`.

`Language` the natural place for this, but also has downstream benefits. Some languages
have multiple `TypeSystem` implementations (ex Swift), and by placing this logic in the
`Language`, redundancy is avoided.

This change relies on the tests from D145348 and D146320.

Differential Revision: https://reviews.llvm.org/D146548