Allow query parameters in parameterized view names

[qiuyanjun888]

Closes: #105037

Parameterized views already accept query parameters for their arguments, but using an Identifier query parameter for the view name produces UNKNOWN_FUNCTION on releases and SYNTAX_ERROR on master. Preserve the unresolved name in ASTFunction until ReplaceQueryParameterVisitor resolves it, while continuing to reject query parameters as ordinary scalar function names. Add stateless coverage for execution, aliases, missing parameters, and AST JSON round-trip.

Changelog category (leave one):

• Bug Fix

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Allow Identifier query parameters to select a parameterized view by name.

[qiuyanjun888]

@nikitamikhaylov could you please review this? This is a scoped follow-up to #106635: ordinary function names still reject query parameters, while function-like table expressions accept an Identifier parameter for parameterized view names.

@vitlibar cc for context.

[clickhouse-gh]

Workflow [PR], commit [bf2108e]

Summary: ❌

job_name	test_name	status	info	comment
Fast test		FAIL
	04812_parameterized_view_qualified_query_parameter_name	FAIL	cidb
Finish Workflow		FAIL
	python3 ./ci/jobs/scripts/workflow_hooks/new_tests_check.py	FAIL
Code Review		DROPPED
Fast test (arm_darwin)		DROPPED
Build (amd_debug)		DROPPED
Build (amd_asan_ubsan)		DROPPED
Build (amd_tsan)		DROPPED
Build (amd_msan)		DROPPED
Build (amd_binary)		DROPPED
Build (arm_debug)		DROPPED

[PedroTadim]

@qiuyanjun888 check the CI failures

[groeneai]

Resolution of the Finish Workflow / Post Hooks (new_tests_check.py) row on my CI finish ledger

I promised a fixing-PR link for this row. There will not be one: I investigated the hook
and concluded no fix to it is warranted. Recording that here rather than leaving the
promise open.

new_tests_check.py reds Post Hooks when no per-arch Bugfix validation job reported a
strict success. Measured over the last 30 days, that happens for two reasons, and neither
is a defect in the hook:

1. The per-arch jobs were dropped or skipped by an upstream failure. In a 12 hour
   sample every one of the 10 rows with this text resolved to a real upstream red on the
   same head (a Fast test failure, a Build (arm_tidy) failure) that dropped the whole
   downstream matrix, or to a genuine "bug does not reproduce on this arch" verdict. The
   hook is relaying that faithfully; suppressing it would remove signal. Fix or re-run the
   upstream job and this row clears on its own.
2. The validation job aborted with no completed test row. I first read this as the
   gate passing on zero evidence. It is not: in 12 of 12 sampled runs the job uploaded a
   core dump whose thread matches that PR's own bug (core.MergeMutate for a mutation
   bug, core.QueryPullPipeEx for a SELECT bug, and so on). On a debug or sanitizer
   master-HEAD binary a reproduced logical error aborts the server, which is exactly a
   zero-row abort, and reconcile_bugfix_crash_repro documents that abort as the bug
   reproducing. So the verdict is correct.

Two smaller diagnostics gaps I am not fixing here, since both change what
clickhouse-test reports rather than fixing a bug: the wedged server's logs are not
collected, so the fatal-message check greps an empty directory and the report shows
Failed: 0, Passed: 0, Skipped: 0 with no hint that a core was captured; and distinct
StopTesting causes are not given distinct exit codes the way the global time limit and
max-failures stops are.