[fix](ui) Fix plan information and counters that Visual Profile drops

[yx-keith]

The MergedProfile parser reads every PlanInfo line and counter an operator reports, but three defects lose or corrupt part of it, and the rest is thrown away before the graph IR is built.

• A parenthesised table name loses its closing parenthesis: table_name=item(item) becomes "item(item". TABLE_NAME_RE excluded "," and ")" but not "(", so the greedy match ran past the opening parenthesis. The name is shown in the operator details and used by the graph search.
• Counter keys could not contain a space, so every counter nested under a parent failed to match and the whole RuntimeFilterInfo subtree was dropped. Nested counters are now kept, keyed "parent/child" by indentation.
• PLAN_INFO_WHITELIST omitted PREDICATES, tablets, pushAggOp, PREAGGREGATION, TOPN OPT and projections, and a line carrying two pairs ("TABLE: t, PREAGGREGATION: ON") leaked the second pair into the first value.

On the captured TPC-DS query 41 scan, the "Plan information" section of the operator details goes from three rows, one of them wrong, to nine correct rows, including the predicates and the tablets read.

Each node also keeps all its counters now, and two derived fields turn text into numbers: planFacts (estimated rows, partitions and tablets selected out of total, pushAggOp, preAggregation, predicates) and runtimeFilters (input, filtered and always-true rows per filter). Nothing renders them yet; they are the input for the diagnostics that follow. The rendered metrics are unchanged.

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[yx-keith]

run buildall