Fixes #142581

This reverts commit daa4061d61216456baa83ab404e096200e327fb4.

Original PR https://github.com/llvm/llvm-project/pull/129092.

I have restricted the test to X86 Windows because it turns out the only
reason that `expr x.get()` would change m_memory_id is that on x86 we
have to write the return address to the stack in ABIWindows_X86_64::PrepareTrivialCall:
```
  // Save return address onto the stack
  if (!process_sp->WritePointerToMemory(sp, return_addr, error))
    return false;
```

This is not required on AArch64 so m_memory_id was not changed:
```
(lldb) expr x.get()
(int) $0 = 0
(lldb) process status -d
Process 15316 stopped
* thread #1, stop reason = Exception 0x80000003 encountered at address 0x7ff764a31034
    frame #0: 0x00007ff764a31038 TestProcessModificationIdOnExpr.cpp.tmp`main at TestProcessModificationIdOnExpr.cpp:35
   32     __builtin_debugtrap();
   33     __builtin_debugtrap();
   34     return 0;
-> 35   }
   36
   37   // CHECK-LABEL: process status -d
   38   // CHECK: m_stop_id: 2
ProcessModID:
  m_stop_id: 3
  m_last_natural_stop_id: 0
  m_resume_id: 0
  m_memory_id: 0
```

Really we should find a better way to force a memory write here, but
I can't think of one right now.

And a follow up warning fix.

This reverts commit 6aa963f780d63d4c8fa80de97dd79c932bc35f4e
and 2bff80f25d51e24d3c552e033a2863dd36ef648b.

This is failing on Windows on Arm: https://lab.llvm.org/buildbot/#/builders/141/builds/8375

Seems to produce the line the test wants but not in the right place.
Reverting while I investigate.

This change adds a setting `target.process.track-memory-cache-changes`.
Disabling this setting prevents invalidating and updating values in
`ValueObject::UpdateValueIfNeeded` when only "internal" debugger memory
is updated. Writing to "internal" debugger memory happens when, for
instance, expressions are evaluated by visualizers (pretty printers).
One of the examples when cache invalidation has a particularly heavy
impact is visualizations of some collections: in some collections
getting collection size is an expensive operation (it requires traversal
of the collection).
At the same time evaluating user expression with side effects (visible
to target, not only to debugger) will still bump memory ID because:

- If expression is evaluated via interpreter: it will cause write to
"non-internal" memory
- If expression is JIT-compiled: then to call the function LLDB will
write to "non-internal" stack memory

The downside of disabled `target.process.track-memory-cache-changes`
setting is that convenience variables won't reevaluate synthetic
children automatically.

---------

Co-authored-by: Mikhail Zakharov <mikhail.zakharov@jetbrains.com>

This introduces the options "-F/--forward" and "-R/--reverse" to
`process continue`.

These only work if you're running with a gdbserver backend that supports
reverse execution, such as rr. For testing we rely on the fake
reverse-execution functionality in `lldbreverse.py`.

This retries the PR 113521 skipping a test in a remote environment.

Reverts llvm/llvm-project#113521 due to build bot failures mentioned in
the original PR.

Internally we use bazel in a way in which it can drop you in a LLDB
session with the target launched in a particular cwd, which is needed
for things to work. We've been making this automation work via `process
launch -w`. However, if later the user wants to restart the process with
`r`, then they end up using a different cwd for relaunching the process.
As a way to fix this, I'm adding a target-level setting that allows
configuring a default cwd used for launching the process without needing
the user to specify it manually.