v0.4.3 — DuckDB 2.0 named-argument compatibility

Compatibility release. No behaviour changes on the v1.5 line; the same source tree now also builds and binds correctly on DuckDB 2.0.

What this fixes

urlpattern_init, url_build and url_modify take named arguments (url_build(protocol := 'https')). DuckDB 2.0 changed how such a function is declared and how it learns its argument names, and only the first half was a compile error.

• Declaration. SimpleFunction::varargs is gone. 2.0 splits it into two parameter kinds: AddArgs (VAR_POSITIONAL, *args) and AddKwargs (VAR_KEYWORD, **kwargs). These functions take keyword arguments, so they now declare AddKwargs plus SetRequiresExpressionNames(true) — matching how DuckDB's own union_value is declared.
• Argument names. On v1.5 a named argument's name is an alias on the bound child (GetAlias()). On 2.0 aliases are empty and names arrive via BindFunctionInput::GetArgumentNames(). A bind body that kept reading GetAlias() would compile on 2.0 and then treat every argument as positional — silently wrong. Both sources are now resolved once into a single list, with positional arguments normalised to the empty string so the bind bodies read identically on both lines.

Verification

Both lines, one source tree, on a 36-core host:

	DuckDB 2.0 b15358c371d	v1.5 line b155d6f63ce
build	0 errors	0 errors
tests	162 assertions, all passed	162 assertions, all passed
url_build(protocol := 'https', hostname := 'example.com', pathname := '/api')	https://example.com/api	identical
url_modify('https://example.com/api', pathname := '/v2')	https://example.com/v2	identical
urlpattern_init(pathname := '/users/:id')	init:A=/users/:id;	identical

b15358c371daf10dad799a43b6167f6ccdce84d8 is the community registry's current default DuckDB (duckdb/community-extensions#3079).

Negative control, because a clean build is not evidence here: declaring *args instead of **kwargs compiles with zero errors and then fails at load with *"A function signature can only have one 'args' parameter". The correctness claim above rests on the queries, not the build.

Closes #14. See #15 for the full discussion, including two C++ traps (GetAlias() returning Identifier on 2.0 in a non-template overload compiled on both lines, and two-phase lookup rejecting the name Identifier inside a discarded if constexpr branch).