Debugger: Make CliContext use BLooper for message passing

This commit replaces the custom implementation of message passing with
BLooper.

This commit does not fully transition the code to the BLooper paradigm.
WaitForEvent still exists, when, ideally, message passing should be
used to notify the waiting class that the results are ready.

Change-Id: Id223b9fc0ac1aa9a5a5aeb4af63da04f2cc7574b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6400
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Rene Gollent <rene@gollent.com>

Debugger: Refactor CliContext::WaitForThreadOrUser

Change-Id: Ic232432f253900a44ad9929cafa46971833cfb5b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6367
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Rene Gollent <rene@gollent.com>

Debugger: improve command help text

Improve the help text of the db, dw, ds, dl, and string commands.

This is accomplished by
* Splitting CliDumpMemoryCommand into CliDumpMemoryCommand and
CliDumpStringCommand
* Moving code shared between the two into CliContext
* Removing functions in CliContext that were replaced by this movement
* Allowing customizing the help text for CliDumpMemoryCommand for each
command it represents
* Changing the help text for CliDumpStringCommand

Change-Id: If4f9e0c20f00f3e3d6c6769216fabb3160aea0a4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6332
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

Debugger: Rework parts of report generation.

Team:
- Adjust report generation event to include a final status code for listeners.

CliContext,TeamWindow,ReportUserinterface:
- Use aforementioned status code to indicate whether report generation
succeeded or failed.

DebugReportGenerator:
- Notify listeners if report generation fails. This may have previously
been responsible for some bug reports where it was indicated that the
debugger hung without exiting after being asked to save a report from
a crashed app.
- When dumping disassembly, retrieve it directly if necessary rather than
requesting it via the user interface listener. This also fixes the quirk
that requesting to save a crash report while looking at the source code
of a function would trigger switching it to disassembly visually.
- When walking the list of threads to dump, acquire references to all of
them before starting. Otherwise, it was potentially possible for a running
but not crashed thread to exit while we were generating the report, leaving
us with a pointer to a deleted thread. This was most likely the cause of one
of the crashes reported in #13082.
- When receiving the notification that source code state has changed, clear
the waiting function. Otherwise, it was potentially possible for us to get
other state change notifications, leading to the data semaphore being
released too often. This would then cause later potential waits such as
the stack frame memory dump to not actually wait when they should,
potentially leading them to dereference objects that weren't yet ready.
This fixes another of the crashes in #13802.

Debugger: Implement remainder of #12729.

UserInterfaceListener:
- Add request hook for writing a core file. Implement in TeamDebugger.

Jobs/WriteCoreFileJob:
- Add new job to actually dispatch the core file request via the debugger
interface.

Team{::Listener}
- Add listener event + hook for notifications when a core file gets written.
Implement in CLI.

CliContext:
- Add event flag for core file changed.

CommandLineUserInterface:
- Add 'write-core' command. This optionally takes a path to write the core to,
otherwise one is automatically generated by, similarly to debug reports. As
such, one can now generate cores for things like app_server and registrar
crashes if desired, in addition to reports.

Debugger: Refactor non-interactive report handling.

- Add dedicated ReportDebugger application class for the case where we're
asked to do nothing more than save a report. Also add a corresponding
UserInterface subclass whose sole purpose is to take those necessary
actions and then exit.
- When the debugger is invoked via the --save-report option, we now start
via the aforementioned report/interface rather than piggybacking on the
CLI.
- Clean up CommandLineUserInterface/CliContext to remove handling for the
report saving option.

Should hopefully resolve #12155.

Debugger: Rework expression parsing API.

ExpressionInfo:
- No longer stores an explicit result type (this is inferred from
evaluation of the expression itself now).
- Introduce class ExpressionResult for returning the result of an
expression computation. This can currently take the form of either
a primitive value, or a value node object.
- Adjust UserInterfaceListener and ExpressionInfo::Listener to take
the above changes into account, and correspondingly adjust all
callers/listeners.

CLanguageExpressionEvaluator:
- Introduce child class Operand. This subsumes the functionality that
was previously in the separate Number class, and can represent a
primitive value, a value node or a type. Also has functionality to
implicity handle type promotion/inferring when performing calculations
between operands.
- Adjust expression parser to operate in terms of Operands rather than
Numbers. This allows a number of improvements, most notably that an
expression can now return a value node as a result rather than only
a primitive number. This capability isn't yet fully used, but paves
the way for future uses such as an expression that evaluates to a data
member, a global variable, or an arbitrary pointer of a particular type.
- Various cleanups/simplifications that were possible as a result of the above
changes.

ExpressionEvaluationWindow/ExpressionPromptWindow:
- Remove type menu field, since the expression API no longer uses it.

Adding/removing expressions in the VariablesView is temporarily disabled,
pending some further rework there to properly handle the new result object.

Debugger: Cleanup.

Team:
- Remove expression evaluation event / listener hook. This doesn't
really belong to the Team anyways.

UserInterfaceListener:
- ExpressionEvaluationRequested() now takes an ExpressionInfo object
rather than the individual subcomponents.

ExpressionEvaluationJob:
- Notification of expression evaluation completion is now handled
via the info object's listener interface rather than the Team.

Others:
- Adjust all users of expressions to set themselves up as
ExpressionInfo::Listener subclasses, and consequently add themselves
to the respective info object when requesting evaluation. This
significantly simplifies various things, and also ensures that no
one accidentally gets notified of an expression they didn't actually
ask for, which could occur with the previous Team-based listener
interface. Make all other required adjustments for new interface
usage.

No functional change intended.

Debugger: Fix #11411.

CliContext/CommandLineUserInterface:
- Process the debug report event asynchronously. The missing lock that
was fixed in commit 5ac34e5a78305abac4c758a34db9f1e34aee54ed highlighted
a problem in how the CLI was handling the case where it was intended to
exit immediately after saving a report, since it issued the quit request
directly from the report event handler. This resulted in locking issues,
as the team debugger would then attempt to tear itself down, during which
it needs to acquire the team lock. However, that was already being held
by the thread in which the CLI was initiating the quit, resulting in a
deadlock.

Debugger: Add expression support to CliContext.

- Extend CliContext::Event to be able to store expression
event results.
- Extend CliContext to watch for team expression events and
handle them accordingly.

Add support for memory block events to CliContext.

More adjustments to CliContext.

- CliContext now listens for value node container events so that
commands can request such a wait as well
- Implement an event wait mechanism for commands to make use of.
Adjust CliStackTrace and CliPrintVariable accordingly.

Various improvements to CliContext.

- CliContext now tracks the current stack trace and frame if applicable.

- CliContext now carries a value node manager. This allows it to track
the variables in the currently active frame.

Debugger CliContext: More event handling, current thread

* Introduce the notion of a current thread. That's the one certain
commands will target (by default).
* Add more event handling in CliContext. There's now a queue of pending
events which are printed in the input loop at convenient times to
inform the user about what happened (new/deleted/stopped threads,
etc.).

Debugger: CliContext: Introduce the notion of events

* The input loop can now wait on abstract events, which other threads
(or even the input loop thread itself) can signal.
* Use the new mechanism in QuitSession().
* Also (with the exception of the SIGINT part) implement
WaitForThreadOrUser().

Debugger CLI: Move more stuff to and extend CliContext

* Move the libedit interface there and provide nicer to use methods.
* Also start adding utility methods for the input loop. It is going to
manage all interactions of the input loop with outside events.
* Fix the "quit" command. The user is now prompted what to do with the
debugged team and the input loop thread avoids reentering the input
loop.

Debugger CLI: Start to imbue CliContext with life

Debugger: Refactor non-interactive report handling.

- Add dedicated ReportDebugger application class for the case where we're
asked to do nothing more than save a report. Also add a corresponding
UserInterface subclass whose sole purpose is to take those necessary
actions and then exit.
- When the debugger is invoked via the --save-report option, we now start
via the aforementioned report/interface rather than piggybacking on the
CLI.
- Clean up CommandLineUserInterface/CliContext to remove handling for the
report saving option.

Should hopefully resolve #12155.

Debugger: Rework expression parsing API.

ExpressionInfo:
- No longer stores an explicit result type (this is inferred from
evaluation of the expression itself now).
- Introduce class ExpressionResult for returning the result of an
expression computation. This can currently take the form of either
a primitive value, or a value node object.
- Adjust UserInterfaceListener and ExpressionInfo::Listener to take
the above changes into account, and correspondingly adjust all
callers/listeners.

CLanguageExpressionEvaluator:
- Introduce child class Operand. This subsumes the functionality that
was previously in the separate Number class, and can represent a
primitive value, a value node or a type. Also has functionality to
implicity handle type promotion/inferring when performing calculations
between operands.
- Adjust expression parser to operate in terms of Operands rather than
Numbers. This allows a number of improvements, most notably that an
expression can now return a value node as a result rather than only
a primitive number. This capability isn't yet fully used, but paves
the way for future uses such as an expression that evaluates to a data
member, a global variable, or an arbitrary pointer of a particular type.
- Various cleanups/simplifications that were possible as a result of the above
changes.

ExpressionEvaluationWindow/ExpressionPromptWindow:
- Remove type menu field, since the expression API no longer uses it.

Adding/removing expressions in the VariablesView is temporarily disabled,
pending some further rework there to properly handle the new result object.

Debugger: Cleanup.

Team:
- Remove expression evaluation event / listener hook. This doesn't
really belong to the Team anyways.

UserInterfaceListener:
- ExpressionEvaluationRequested() now takes an ExpressionInfo object
rather than the individual subcomponents.

ExpressionEvaluationJob:
- Notification of expression evaluation completion is now handled
via the info object's listener interface rather than the Team.

Others:
- Adjust all users of expressions to set themselves up as
ExpressionInfo::Listener subclasses, and consequently add themselves
to the respective info object when requesting evaluation. This
significantly simplifies various things, and also ensures that no
one accidentally gets notified of an expression they didn't actually
ask for, which could occur with the previous Team-based listener
interface. Make all other required adjustments for new interface
usage.

No functional change intended.

Debugger: Fix #11411.

CliContext/CommandLineUserInterface:
- Process the debug report event asynchronously. The missing lock that
was fixed in commit 5ac34e5a78305abac4c758a34db9f1e34aee54ed highlighted
a problem in how the CLI was handling the case where it was intended to
exit immediately after saving a report, since it issued the quit request
directly from the report event handler. This resulted in locking issues,
as the team debugger would then attempt to tear itself down, during which
it needs to acquire the team lock. However, that was already being held
by the thread in which the CLI was initiating the quit, resulting in a
deadlock.

Debugger: Add expression support to CliContext.

- Extend CliContext::Event to be able to store expression
event results.
- Extend CliContext to watch for team expression events and
handle them accordingly.

Add support for memory block events to CliContext.

More adjustments to CliContext.

- CliContext now listens for value node container events so that
commands can request such a wait as well
- Implement an event wait mechanism for commands to make use of.
Adjust CliStackTrace and CliPrintVariable accordingly.

Various improvements to CliContext.

- CliContext now tracks the current stack trace and frame if applicable.

- CliContext now carries a value node manager. This allows it to track
the variables in the currently active frame.

Debugger CliContext: More event handling, current thread

* Introduce the notion of a current thread. That's the one certain
commands will target (by default).
* Add more event handling in CliContext. There's now a queue of pending
events which are printed in the input loop at convenient times to
inform the user about what happened (new/deleted/stopped threads,
etc.).

Debugger: CliContext: Introduce the notion of events

* The input loop can now wait on abstract events, which other threads
(or even the input loop thread itself) can signal.
* Use the new mechanism in QuitSession().
* Also (with the exception of the SIGINT part) implement
WaitForThreadOrUser().

Debugger CLI: Move more stuff to and extend CliContext

* Move the libedit interface there and provide nicer to use methods.
* Also start adding utility methods for the input loop. It is going to
manage all interactions of the input loop with outside events.
* Fix the "quit" command. The user is now prompted what to do with the
debugged team and the input loop thread avoids reentering the input
loop.

Debugger CLI: Start to imbue CliContext with life