Document, deprecate, and remove `SqlErr`

SqlErr is a very incomplete, outdated, and unmaintained reimplementation of sqlx::DatabaseError. We shouldn't have it. This is a strong opinion.

As a user, it sent me down the wrong path. For months, I was doing a fragile text search of my unique index names in SqlErr::UniqueConstraintViolation(error_text). I've just learned that I can match sqlx::DatabaseError, and then simply call database_error.constraint() to get the index name. And that it can also detect and parse CHECK constraint violations for me. I'm mad.

If we're not ready to break the compatibility and remove SqlErr yet, we should definitely document these nuances now, and deprecate SqlErr sometime later in 2.x (keeping the 2.0 migration as easy as we can).

What to give our users instead

What we should actually do for ergonomic DatabaseError handling, is to provide a db_err.database_error() method. Easy, right? I know. We can even mention it the .sql_err() deprecation message.

On a side note

Now I hate the sea_orm::DbErr naming. It should've been sea_orm::Error. sqlx::DatabaseError makes much more sense, because that's an error returned from the database.

In an ideal world, unconcerned with compatibility and churn, I would introduce sea_orm::Error, turn sea_orm::DbErr into an alias, and deprecate it sometime later in 2.x.

Start by locating the existing SqlErr, DbErr, and sql_err() APIs, then review how sqlx::DatabaseError is currently exposed or matched. Done requires a decided compatibility plan plus the corresponding documentation, deprecation or removal work, and ergonomic database-error API changes; the issue does not name files or tests.