Add support for retrieving `HTMLElement` by Dash component ID in clientside callbacks.

This has been discussed on the forum. A feature request seems more appropriate.

Is your feature request related to a problem? Please describe.
When using clientside callbacks and pattern matching, the idiomatic for getting access to third party javascript objects seems to be (an example from ag Grid) :

clientside_callback(
    """
(grid_id, html_id, ...) => {
  // works 
  const gridApi = dash_ag_grid.getApi(id);
  // doesn't work
  const el = document.querySelector(`div#{html_id}`);
}
    """,
    Output(MATCH, "id"),
    Input({"type": "ag-grid", "index": MATCH}, "id"),
    Input({"type": "html-element", "index": MATCH}, "id"),
    # ... any other inputs that would be used here to trigger this behavior
)

Describe the solution you'd like
I would like Dash to expose a method like dash_clientside.get_element_by_id(id: String | Object<String, String | _WildCard>): HTMLElement which takes advantage of dash internals correctly to replicate this use case.

Describe alternatives you've considered
There is a forum post describing an implementation of stringifyId that can query HTMLElements using document.querySelector. However, even the author acknowledges that the behavior may not be consistent, and runtime checks are necessary to ensure correctness. Plus, if Dash ever changes how object IDs are serialized for use in the DOM, any projects depending on this solution will break in unexpected ways.

Inizia tracciando il clientside callback entry point e la dash_clientside API, quindi confronta la ricerca richiesta con l’alternativa document.querySelector descritta nell’issue. Il lavoro è completato quando un metodo supportato recupera in modo affidabile l’HTMLElement previsto per Dash IDs di tipo string e di tipo object o wildcard, e il comportamento rilevante è coperto dai test.