Future R Language change requests / contributions

While developing this, I found that there are a few features that are unfortunately quite difficult to implement. Some of which can be made significantly simpler with a few changes to the R language. This issue catalogs those changes.

# Change Requests

## :question: Top level pre-execution hook

Currently we have `addTaskCallback` to register callbacks for code to run _after_ a top level expression, but unfortunately have no mechanism of registering code to run _before_ each top level expression.

Without this feature, debug statements are processed only upon each top level expression's completion in the REPL, meaning that the state of the debugger in the REPL lags behind the state of the debugger in the IDE and is only synchronized after a top level callback.

With this feature, any new breakpoint traces can be set before user input is evaluated, minimizing debugger state desync.

## :white_check_mark: Browser callback hooks

Currently a "shadow" browser is used, which introduces an enormous amount of complexity to the project. The browser prompt is a fixed part of the R language with almost no opportunities to inject code in its REPL. To handle this, a process is forked and its output is split between the REPL presented to the user while commands and output required for the debugger are hidden and communicate directly with the DAP server.

Instead, if hooks could be added to the browser REPL akin to the standard REPL task callbacks, then this code could be executed in the foreground process directly without cluttering the REPL output with messy server messaging calls.

## Step Information in Browser Hook

- Getting access to the _expression_ that is being debugged, not just the `sys.call()`. Ideally with position information within the evaluating function. This seems to be accessible in-between browser steps at the C level ([SrcrefPrompt](https://github.com/wch/r-source/blob/56509cd8d689fd69d6669d30d73a67b840eaaae3/src/main/eval.c#L1313-L1315), but I can't figure out how to grab this information on the R side. Update: this is available in `debug()` prompts, but not `browser()` prompts
- Would be nice to have some information about what stepping commands are issued in the browser hook (`n`, `s`, `c`, etc)
- `condition` argument of `debug()` appears to be broken?
```r
f <- function(x) { x }
debug(f, condition = list(test = 123))
f()
#> Browse[1]> browserCondition()
#> NULL
```
- Would love a way to disable the `debug at #: ...` text that gets spit out during each debug step now that browser hooks allow for custom-built prompts.

### Other mentions of this limitation

The core challenge imposed by having a rather fixed debug browser was also felt in the `vscDebugger` project, which got around this challenge by running a separate R process governed by javascript. This method relies on parsing of stdout.

> ##### _from https://github.com/ManuelHentschel/VSCode-R-Debugger/issues/156#issuecomment-990167766_
> The main problem with the vscDebugger package is that there seems to be no way to control the program flow (stepping through code while debugging) from within R itself. Therefore, I am using a node-based wrapper, which controls the input to/output from an R process underneath.