[lldb] Clear stale error in Target::ReadMemory on file-cache fallback (#213451)

Load the checked-in core `linux-aarch64-pac.core` from
`lldb/test/API/functionalities/postmortem/elf-core/` with its binary and ask for
a `char16_t *` summary at the start of `.text`:

```
(lldb) settings set target.max-string-summary-length 8
(lldb) expression -l c++ -- (char16_t *)0x400140
(char16_t *) $0 = 0x0000000000400140 unable to read data
(lldb) memory read -s1 -c16 0x400140
0x00400140: 3f 23 03 d5 ff 83 00 d1 fd 7b 01 a9 fd 43 00 91  ?#.......{...C..
```

`memory read` prints the very bytes the summary just claimed it could not read.
Both go through `Target::ReadMemory()`, which reuses a single `Status &error` for
the process read and for the file-cache fallback at the end of the function, and
`Target::ReadMemoryFromFileCache()` only ever sets that `Status`, it never clears
it.  So when the process read fails outright and the fallback then satisfies the
whole request, `ReadMemory()` returns the correct bytes with the failed process
read's message still in `error`.  `memory read` only compares the returned count
against the requested length, so it is fine, but
`Target::ReadStringFromMemory()`, which `StringPrinter` uses for UTF-16 and
UTF-32, gives up on `error.Fail()`, and `SBTarget::ReadMemory()` hands the same
stale `Status` to any scripted client.

Core files reach this routinely.  `ProcessMachCore` and `ProcessElfCore` both
report `IsAlive()`, so the process read is attempted and fails for a page that
was not dumped into the core, and the fallback then serves that page out of the
binary on disk.  In this core the `PT_LOAD` covering `.text` has
`p_filesz == 0`.

Clear `error` before the fallback so the bytes and the `Status` describe the same
read, and let the fallback report a short read itself:
`ReadMemoryFromFileCache()` sets an error when it reads nothing, but not when
`ObjectFile::ReadSectionData()` clamps a request that overruns the section.  A
short read is only a failure when a live read already produced nothing, hence the
`ProcessIsValid()` guard: without it a target with no process, say one made from
a `.o` file where the fallback is the only reader, fails legitimate short reads.
`Target::ReadInstructions()` asks for `GetMaximumOpcodeByteSize() * count` bytes
and bails on `error.Fail()`, so it could no longer disassemble the tail of a
section.

The one change for callers is that a full read served by the fallback now
reports success.  (The session lowers `target.max-string-summary-length` to keep
the request inside this binary's small `.text`; a larger request really is a
short read and still reports an error.)

```
(lldb) expression -l c++ -- (char16_t *)0x400140
(char16_t *) $0 = 0x0000000000400140 u"⌿픃菿턀篽꤁䏽"
```

A unit test in `lldb/unittests/Target/MemoryTest.cpp` drives the fallback with a
process that cannot produce a byte, checking that a full read succeeds and a
short one does not, and `test_read_only_cstring` in `TestLinuxCore.py` gains an
`SBTarget::ReadMemory()` check on the core it already loads.

GitOrigin-RevId: 51e8f76e2883013a7e6452d06e0835291bd78403