[Bug]: Changing a connection's type clears username, password, host and database name

### Apache Hop version?

2.20

### Java version?

21

### Operating system

Windows

### What happened?

## Problem

When changing the connection type of an existing database connection — for example from MySQL to
MariaDB, to use another driver for the same server — Hop clears the hostname, database name,
username and password, and replaces the port with the new type's default.

Changing the adapter should not require entering the same connection details again. The password in
particular cannot be read back off the screen. The same applies when switching to a different
database family, MySQL to SQL Server, say: host, database name, user and password are still what
the user typed, and most of them still apply. This is even more so when the fields hold variables
rather than literal values — `${DB_HOST}`, `${DB_USER}`, `${DB_PASSWORD}` — which is how we set up
most connections: the variable names are the same whatever the database type, so nothing about
them needs to change. It is easier to correct one field than to re-enter all of them.

## Steps to reproduce

`main` @ `e487fe70f5`.

1. Metadata perspective → Relational Database Connection → open one with hostname, database name,
username and password filled in (MySQL, say).
2. Change **Connection type** to a type not selected before in this editor session — MariaDB,
PostgreSQL, Infobright.
3. Hostname, database name, username and password are empty. Port is the new type's default.

Switching *back* to the type you started on restores its values.

## Expected behavior

- Preserve the connection details on every type change — within a family and across families —
including an explicitly entered port or a variable reference in the port field.
- If the port field is empty, use the selected type's default port if it has one; otherwise leave
it empty.
- Preserve type-specific settings when switching back to a previously selected type — that already
works today.

## Why

`DatabaseMetaEditor.changeConnectionType()` (`:549`) first calls `DatabaseMeta.setDatabaseType`
(`core/.../DatabaseMeta.java:298`), which builds the new `IDatabase` and copies the common
connection fields onto it. The next line (`:580`) replaces that instance with one from `metaMap`:

```java
databaseMeta.setDatabaseType(newTypeName); // :577
databaseMeta.setIDatabase(metaMap.get(databaseMeta.getIDatabase().getClass())); // :580
```

`metaMap` is pre-filled by `populateMetaMap()` (`:170`) with an empty instance of every database
plugin, initialized with the type's default port and default options. On the first switch to a type
the lookup hits that empty instance, and the fields just copied are gone.

## Proposed fix

Keep the cached instance for its type-specific settings, then copy the current connection details
(hostname, database name, username, password, servername, tablespaces, access type) onto it. For
the port: copy it when it is filled in; when it is empty, use the selected type's default if
available — otherwise leave it empty — instead of restoring an old cached port.

One method plus a small private helper in `DatabaseMetaEditor`. Happy to open the PR if the
approach looks right.

Once the port survives a type change, the obvious follow-up question is how to get the new type's
default when you do want it. We answered that with a small **Default port** button to the right of
the port field: it fills in the selected type's `getDefaultDatabasePort()` on demand, and is only
shown for types that declare one. It is the piece that makes "keep the port" safe to do without a
heuristic. Happy to include it in the same PR, or propose it separately if you would rather keep the
defect fix minimal.

### Issue Priority

Priority: 3

### Issue Component

Component: Hop Gui

Start in DatabaseMetaEditor.changeConnectionType(), especially the calls around lines 549-580, and inspect DatabaseMeta.setDatabaseType() in core/.../DatabaseMeta.java plus populateMetaMap() around line 170. Verify how cached database instances and default ports are selected. Done means connection details and explicit ports survive type changes, while an empty port uses the selected type's default when available; previously cached type-specific settings still remain intact.

Written by the indexing model from the issue text.