This reverts commit 00ffd8b8aa4e8cd3a2fee654d55995918886e874.

The change breaks lldb greendragon tests

Namely, TestClangREPL.py

Fixes https://github.com/llvm/llvm-project/issues/153157

The proposed solution has been discussed here
(https://github.com/llvm/llvm-project/issues/153157#issue-3313379242)

This is what we would be seeing now 

```
base) anutosh491@Anutoshs-MacBook-Air bin % ./lldb /Users/anutosh491/work/xeus-cpp/a.out
(lldb) target create "/Users/anutosh491/work/xeus-cpp/a.out"
Current executable set to '/Users/anutosh491/work/xeus-cpp/a.out' (arm64).
(lldb) b main
Breakpoint 1: where = a.out`main, address = 0x0000000100003f90
(lldb) r
Process 71227 launched: '/Users/anutosh491/work/xeus-cpp/a.out' (arm64)
Process 71227 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100003f90 a.out`main
a.out`main:
->  0x100003f90 <+0>:  sub    sp, sp, #0x10
    0x100003f94 <+4>:  str    wzr, [sp, #0xc]
    0x100003f98 <+8>:  str    w0, [sp, #0x8]
    0x100003f9c <+12>: str    x1, [sp]
(lldb) expression --repl -l c -- 
  1> 1 + 1
(int) $0 = 2
  2> 2 + 2
(int) $1 = 4
```

```
base) anutosh491@Anutoshs-MacBook-Air bin % ./lldb /Users/anutosh491/work/xeus-cpp/a.out
(lldb) target create "/Users/anutosh491/work/xeus-cpp/a.out"
Current executable set to '/Users/anutosh491/work/xeus-cpp/a.out' (arm64).
(lldb) b main
Breakpoint 1: where = a.out`main, address = 0x0000000100003f90
(lldb) r
Process 71355 launched: '/Users/anutosh491/work/xeus-cpp/a.out' (arm64)
Process 71355 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100003f90 a.out`main
a.out`main:
->  0x100003f90 <+0>:  sub    sp, sp, #0x10
    0x100003f94 <+4>:  str    wzr, [sp, #0xc]
    0x100003f98 <+8>:  str    w0, [sp, #0x8]
    0x100003f9c <+12>: str    x1, [sp]
(lldb) expression --repl -l c -- 3 + 3
Warning: trailing input is ignored in --repl mode
  1> 1 + 1
(int) $0 = 2
```

This fixes a few bugs, effectively through a fallback to `p` when `po` fails.

The motivating bug this fixes is when an error within the compiler causes `po` to fail.
Previously when that happened, only its value (typically an object's address) was
printed – and problematically, no compiler diagnostics were shown. With this change,
compiler diagnostics are shown, _and_ the object is fully printed (ie `p`).

Another bug this fixes is when `po` is used on a type that doesn't provide an object
description (such as a struct). Again, the normal `ValueObject` printing is used.

Additionally, this also improves how lldb handles an object description method that
fails in some way. Now an error will be shown (it wasn't before), and the value will be
printed normally.

When dumping variables, LLDB will print a one-time warning about
truncating children (when the children count exceeds the default
`target.max-children-count`). But we only do this for `frame variable`.
So if we use `dwim-print` or `expression`, the output gets truncated but
we don't print a warning. But because we store the fact that we
truncated some output on the `CommandInterpreter`, we fire the warning
next time we use `frame variable`. E.g.,:
```
(lldb) p arr
(int[1000]) {
  [0] = -5
  [1] = 0
  [2] = 0
  <-- snipped -->
  [253] = 0
  [254] = 0
  [255] = 0
  ...
}
(lldb) v someLocal
(int) someLocal = 10
*** Some of the displayed variables have more members than the debugger
will show by default. To show all of them, you can either use the
--show-all-children option to frame variable or raise the limit by
changing the target.max-children-count setting.
```

This patch prints the warning for `dwim-print` and `expression`.

I only added a test for the `target.max-children-count` for now because
it seems the `target.max-children-depth` warning is broken (I can't get
it to fire).

This patch improves the synchronization of the debugger's output and error
streams using two new abstractions: `LockableStreamFile` and
`LockedStreamFile`.

 - `LockableStreamFile` is a wrapper around a `StreamFile` and a mutex. Client
   cannot use the `StreamFile` without calling `Lock`, which returns a
   `LockedStreamFile`.

 - `LockedStreamFile` is an RAII object that locks the stream for the duration
   of its existence.  As long as you hold on to the returned object you are
   permitted to write to the stream. The destruction of the object
   automatically flush the output stream.

There are a lot of lldb commands whose result is really one or more
ValueObjects that we then print with the ValueObjectPrinter. Now that we
have the ability to access the SBCommandReturnObject through a callback
(#125006), we can store the resultant ValueObjects in the return object,
allowing an IDE to access the SBValues and do its own rich formatting.

rdar://143965453

Similar to #126821, in support of #126630.

This allows IDEs to render LLDB expression diagnostics to their liking
without relying on characterprecise ASCII art from LLDB. It is exposed
as a versioned SBStructuredData object, since it is expected that this
may need to be tweaked based on actual usage.

and implement them for dwim-print (a.k.a. `p`) as an example.

The next step will be to expose them as structured data in
SBCommandReturnObject.

This is a cleanup that moves the API towards value semantics.