feat: Avoid throwing errors for shared input/output IDs

[gadenbuie]

Fixes #4100

Description

This PR refactors the Shiny Client Error console to allow client error messages to be communicated via events in addition to errors.

The primary goal is to avoid throwing an error from the binding validity checks for shared input/output ID errors. In practice, there were two problems with the binding validity checks throwing errors:

1. There are many cases where an app with shared IDs may still work, but by throwing an error we guarantee that the app breaks. Because we throw the error from Shiny's initialization code, we absolutely guarantee the app will not work, even if in practice the ID collision would not have caused problems.

2. We were previously guarding some errors behind dev mode being enabled, meaning that turning on dev mode could break an app that otherwise works. IMHO, dev mode should add information by showing users additional context or inforamtion, but should not introduce large breaking changes into the app.

By allowing the client error console to receive messages via event, we can now have bindAll() report binding issues without throwing or breaking the app.

This refactor also improves the code organization and opens us up to future improvements in a few ways:

• I consolidated the message display logic so that the client error console handles redirecting messages to the console when dev mode is not enabled.
• A client message is currently assumed to be an error, but we can now easily expand the properties of a ShinyClientMessage in the future to add, for example, informational messages differentiated by a type prop.
• The event handler approach opens the client error console to third-party use-cases via the shiny:client-message event.

Note that we do still throw an error when we detect more than one of the same input IDs or output IDs (i.e. "debug" is used for two+ inputs or is used for two+ outputs). In theory, these apps could still work but would be much harder to reason about. More importantly, by still throwing in these cases, this PR only changes behavior in the narrow case of the shared input/output ID.

Example

The following app currently works as expected in "production" but breaks when devmode is enabled. With this PR, the app works in both modes and a message is shown either in the console or in the client error console when devmode is enabled.

library(shiny)
library(bslib)

options(shiny.devmode = TRUE)

ui <- page_fluid(
  actionButton("debug", "Debug"),
  # textInput("debug", "Other debug"),
  verbatimTextOutput("debug")
)

server <- function(input, output, session) {
  output$debug <- renderPrint({
    input$debug
  })
}

shinyApp(ui, server)

The problem can be seen in this shinylive.io app (as of 2024-07-15).