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.

Start by tracing the clientside callback entry point and the dash_clientside API, then compare the requested lookup with the document.querySelector alternative described in the issue. Done means a supported method reliably retrieves the intended HTMLElement for string and object or wildcard Dash IDs, with the relevant behavior covered by tests.