Support custom `database/sql` driver names in generated `Client.Open`

- [x] I have searched the [issues](https://github.com/ent/ent/issues) of this repository and believe that this is not a duplicate.

## Summary 💡

The generated `Client.Open(driverName, dataSourceName, ...)` API currently uses the same string both as:

1. the ent SQL dialect
2. the `database/sql` driver registration name

This works for the default documented paths, but it becomes awkward when using custom SQL drivers whose registration name does not match the ent dialect name.

A concrete example is SQLite with pure-Go or wrapped drivers. The lower-level integration path already works today:

```go
db, err := sql.Open("sqlite", dsn)
if err != nil {
return err
}
drv := entsql.OpenDB(dialect.SQLite, db)
client := ent.NewClient(ent.Driver(drv))
```

However, the generated `Client.Open(...)` path rejects this case because it only accepts the built-in dialect names.

I would like to propose exposing this use case more directly in generated clients, for example by either:

1. adding a generated helper such as `OpenDB(dialectName string, db *sql.DB, options ...Option)`, or
2. allowing `Client.Open(...)` to override the actual `database/sql` driver registration name while still keeping the ent dialect explicit

The goal is not to support one specific package, but to support custom SQL driver registration names in a dialect-safe way.

## Motivation 🔦

At the moment, this is already possible through `sql.DB` integration, so this is not a missing low-level capability.

The issue is mainly about generated client ergonomics and API clarity:

- users naturally try `Client.Open(...)` first
- custom or wrapped SQL drivers fail there even when the ent dialect is known
- the workaround requires dropping to a lower-level initialization pattern that is documented, but easy to miss

This affects SQLite most obviously, but the underlying problem is more general: the ent dialect and the `database/sql` driver registration name are different concepts and do not always match.

Before preparing a PR, I wanted to ask whether this is something the project would want to address in generated client APIs, and if so, whether a generated `OpenDB(...)` helper or an extension of `Client.Open(...)` would be preferred.