The LLVM Style Guide says the following about error and warning messages
[1]:

> [T]o match error message styles commonly produced by other tools,
> start the first sentence with a lowercase letter, and finish the last
> sentence without a period, if it would end in one otherwise.

I often provide this feedback during code review, but we still have a
bunch of places where we have inconsistent error message, which bothers
me as a user. This PR identifies a handful of those places and updates
the messages to be consistent.

[1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages

Whenever an option would use something other than the first letter of
the long option as the short option, Jim would capitalized the letter we
picked as a mnemonic. This has often been mistaken for a typo and Jim
wondered if we should stop doing this.

During the discussion, David mentioned how this reminds him of the
underline in menu bars when holding down alt. I suggested we do
something similar in LLDB by underlying the letter in the description.

https://discourse.llvm.org/t/should-we-remove-the-capital-letter-in-option-helps/87816

### Summary
Currently `target modules dump separate separate-debug-info`
automatically loads up all DWO files, even if deferred loading is
enabled through debug_names. Then, as expected all DWO files (assuming
there is no error loading it), get marked as "loaded".

This change adds the option `--force-load-all-debug-info` or `-f` for
short to force loading all debug_info up, if it hasn't been loaded yet.
Otherwise, it will change default behavior to not load all debug info so
that the correct DWO files will show up for each modules as "loaded" or
not "loaded", which could be helpful in cases where we want to know
which particular DWO files were loaded.

### Testing
#### Unit Tests
Added additional unit tests
`test_dwos_load_json_with_debug_names_default` and
`test_dwos_load_json_with_debug_names_force_load_all` to test both
default behavior and loading with the new flag
`--force-load-all-debug-info`, and changed expected behavior in
`test_dwos_loaded_symbols_on_demand`.
```
bin/lldb-dotest -p TestDumpDwo ~/llvm-project/lldb/test/API/commands/target/dump-separate-debug-info/dwo
```

#### Manual Testing
Compiled a simple binary w/ `--gsplit-dwarf --gpubnames` and loaded it
up:
```
(lldb) target create "./a.out"
Current executable set to '/home/qxy11/hello-world/a.out' (x86_64).
(lldb) help target modules dump separate-debug-info
List the separate debug info symbol files for one or more target modules.

Syntax: target modules dump separate-debug-info <cmd-options> [<filename> [<filename> [...]]]

Command Options Usage:
  target modules dump separate-debug-info [-efj] [<filename> [<filename> [...]]]

       -e ( --errors-only )
            Filter to show only debug info files with errors.

       -f ( --force-load-all-debug-info )
            Load all debug info files.

       -j ( --json )
            Output the details in JSON format.

     This command takes options and free-form arguments.  If your arguments resemble option specifiers (i.e., they start with a - or --), you must use ' -- ' between the end of the
     command options and the beginning of the arguments.
(lldb) target modules dump separate-debug-info --j
[
  {
    "separate-debug-info-files": [
      {  ...
        "dwo_name": "main.dwo",
        "loaded": false
      },
      {  ...
        "dwo_name": "foo.dwo",
        "loaded": false
      },
      { ...
        "dwo_name": "bar.dwo",
        "loaded": false
      }
    ],
  }
]
(lldb) b main
Breakpoint 1: where = a.out`main + 15 at main.cc:3:12, address = 0x00000000000011ff
(lldb) target modules dump separate-debug-info --j
[
  {
    "separate-debug-info-files": [
      { ...
        "dwo_name": "main.dwo",
        "loaded": true,
        "resolved_dwo_path": "/home/qxy11/hello-world/main.dwo"
      },
      { ...
        "dwo_name": "foo.dwo",
        "loaded": false
      },
      { ...
        "dwo_name": "bar.dwo",
        "loaded": false
      }
    ],
  }
]
(lldb) b foo
Breakpoint 2: where = a.out`foo(int) + 11 at foo.cc:12:11, address = 0x000000000000121b
(lldb) target modules dump separate-debug-info --j
[
  {
    "separate-debug-info-files": [
      { ...
        "dwo_name": "main.dwo",
        "loaded": true,
        "resolved_dwo_path": "/home/qxy11/hello-world/main.dwo"
      },
      { ...
        "dwo_name": "foo.dwo",
        "loaded": true,
        "resolved_dwo_path": "/home/qxy11/hello-world/foo.dwo"
      },
      { ...
        "dwo_name": "bar.dwo",
        "loaded": false
      }
    ],
  }
]
(lldb) b bar
Breakpoint 3: where = a.out`bar(int) + 11 at bar.cc:10:9, address = 0x000000000000126b
(lldb) target modules dump separate-debug-info --j
[
  {
    "separate-debug-info-files": [
      { ...
        "dwo_name": "main.dwo",
        "loaded": true,
        "resolved_dwo_path": "/home/qxy11/hello-world/main.dwo"
      },
      { ...
        "dwo_name": "foo.dwo",
        "loaded": true,
        "resolved_dwo_path": "/home/qxy11/hello-world/foo.dwo"
      },
      { ...
        "dwo_name": "bar.dwo",
        "loaded": true,
        "resolved_dwo_path": "/home/qxy11/hello-world/bar.dwo"
      }
    ],
  }
]
```

The `current_module` pointer here was never set, but we check it when
looping over the `target_modules` list. Presumably the intention was to
avoid calling `LookupInModule` if we already found the type in the
current module. This patch removes this `current_module`. If we decide
the output below is not what the user should see, we can revisit the
implementation.

Current output:
```
(lldb) im loo -vt Foo --all
Best match found in /Users/jonas/Git/llvm-worktrees/llvm-project/a.out:
id = {0x00000037}, name = "Foo", byte-size = 1, decl = foo.cpp:1, compiler_type = "struct Foo {
}"

1 match found in /Users/jonas/Git/llvm-worktrees/llvm-project/a.out:
id = {0x00000037}, name = "Foo", byte-size = 1, decl = foo.cpp:1, compiler_type = "struct Foo {
}"
```
which seems fine.

Note, there can be multiple matches *within* the current module, so if
we did the naive thing of skipping the `current_module` when printing
with `--all`, then we would miss some matches.

The help output for `target stop-hook add` references non-existing
option `--one-line-command`. The correct option is `--one-liner`:

```
-o <one-line-command> ( --one-liner <one-line-command> )
     Add a command for the stop hook.  Can be specified more than once,
     and commands will be run in the order they appear.
```

This commit fixes the help text.

rdar://152730660

Depends on https://github.com/llvm/llvm-project/pull/142163

This patch makes the `-ast-dump-filter` Clang option available to the
`target modules dump ast` command. This allows us to selectively dump
parts of the AST by name.

The AST can quickly grow way too large to skim on the console. This will
aid in debugging AST related issues.

Example:
```
(lldb) target modules dump ast --filter func
Dumping clang ast for 48 modules.
Dumping func:
FunctionDecl 0xc4b785008 <<invalid sloc>> <invalid sloc> func 'void (int)' extern
|-ParmVarDecl 0xc4b7853d8 <<invalid sloc>> <invalid sloc> x 'int'
`-AsmLabelAttr 0xc4b785358 <<invalid sloc>> Implicit "_Z4funcIiEvT_"

Dumping func<int>:
FunctionDecl 0xc4b7850b8 <<invalid sloc>> <invalid sloc> func<int> 'void (int)' implicit_instantiation extern
|-TemplateArgument type 'int'
| `-BuiltinType 0xc4b85b110 'int'
`-ParmVarDecl 0xc4b7853d8 <<invalid sloc>> <invalid sloc> x 'int'
```

The majority of this patch is adjust the `Dump` API. The main change in
behaviour is in `TypeSystemClang::Dump`, where we now use the
`ASTPrinter` for dumping the `TranslationUnitDecl`. This is where the
`-ast-dump-filter` functionality lives in Clang.

stop-hooks are supposed to trigger every time the process stops, but as
initially implemented they would only fire when control was returned to
the user. So for instance when a process was launched the stop hook
would only trigger when the process hit a breakpoint or crashed.

However, it would be really useful to be able to trigger a stop hook
when lldb first gains control over the process. One way to do that would
be to implement general "target lifecycle events" and then send process
created events that users could bind actions to.

OTOH, extending the stop hooks to fire when lldb first gains control
over the process is a pretty natural extension to the notion of a stop
hook. So this patch takes the shorter route to that ability by making
stop-hooks fire when lldb first gains control over the process.

I also added the ability to specify whether to trigger the stop hook "on
gaining control". I'm on the fence about whether to set the default to
be "trigger on gaining control" or "don't trigger on gaining control".
Since I think it's a generally useful feature, I've set the default to
"trigger on gaining control".

This PR makes it so that `CompilerInvocation` needs to be provided to
`CompilerInstance` on construction. There are a couple of benefits in my
view:
* Making it impossible to mis-use some `CompilerInstance` APIs. For
example there are cases, where `createDiagnostics()` was called before
`setInvocation()`, causing the `DiagnosticEngine` to use the
default-constructed `DiagnosticOptions` instead of the intended ones.
* This shrinks `CompilerInstance`'s state space.
* This makes it possible to access **the** invocation in
`CompilerInstance`'s constructor (to be used in a follow-up).

This reverts commit 094904303d50e0ab14bc5f2586a602f79af95953, reapplying
d7afafdbc464e65c56a0a1d77bad426aa7538306 (#133247).

The failure ought to be fixed by
0509932bb6a291ba11253f30c465ab3ad164ae08.