Lifecycle problem with UDF functions

### What happens?

There seems to be some sort of lifecycle problem with registered udf Functions. For now this can be easily worked around by kepping a strong reference to that function somewhere in python.

If this is not done you risk getting a sigsev when executing it.

I am not quite sure if this behavior should be allowed at all. So a possible fix for this might be to remove all udf functions that were registered on that cursor / connection when cleaning / closing that connection.

### To Reproduce

This is the minimum that is needed to get a reliable segfault (at least on my machine - linux with duckdb wheel 1.5.4).

```
import duckdb

con = duckdb.connect()
cur = con.cursor()
cur.create_function("myf", lambda x: f"got:{x}", ["VARCHAR"], "VARCHAR")
del cur
print("calling myf via con after cursor teardown...", flush=True)
result = con.sql("SELECT myf('b')").fetchall() # dangling raw PyObject* -> SIGSEGV

# Not reached when the bug is present.
print("result:", result)
```

Ouput:
```
calling myf via con after cursor teardown...
Speicherzugriffsfehler (Speicherabzug geschrieben)
```

### OS:

linux

### DuckDB Package Version:

1.5.4

### Python Version:

3.14

### Full Name:

-

### Affiliation:

-

### What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a stable release

### Did you include all relevant data sets for reproducing the issue?

Yes

### Did you include all code required to reproduce the issue?

- [x] Yes, I have

### Did you include all relevant configuration to reproduce the issue?

- [x] Yes, I have