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

[xjeway]

• I have searched the 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:

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.