Improve exception handling for CREATE TABLE task

[findinpath]

Provide meaningful exception message for CREATE TABLE task
when dealing with namesake table of unsupported type in
shared metastore.

This change affects the connectors: hive, iceberg, delta lake
which may deal with a shared metastore (HMS/AWS Glue).

Description

Is this change a fix, improvement, new feature, refactoring, or other?

Fix

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

This change affects the core query engine (CreateTableTask)

How would you describe this change to a non-technical end user or system administrator?

In the context of using shared metastore between Hive, Iceberg/Delta it may very well happen that the users are trying to create a namesake table from two different connectors. This PR improves exception handling in the CREATE TABLE task to provide a meaningful message to the user in such a situation.

Related issues, pull requests, and links

Fixes #10446

Documentation

(x) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

( ) No release notes entries required.
(x) Release notes entries required with the following suggested text:

# Main
* Improve exception handling in`CREATE TABLE` task when dealing with namesake table of unsupported type in
shared metastore.

[findepi]

cc @electrum

[alexjo2144]

Looks reasonable to me.

There's a bigger question along with #11617 I guess. Should connectors ever hide unsupported tables? Now that we have table redirections it seems to me like we should never filter tables, and so these create table statements should always see the existing tables rather than relying on catching it with the exception code.

[findinpath]

@alexjo2144 good point.

I would rather put this PR on hold until #11617 is cleared and then act accordingly.

Calling io.trino.metadata.Metadata#listTables instead of io.trino.metadata.Metadata#getTableHandle(io.trino.Session, io.trino.metadata.QualifiedObjectName) would spare us of the exception code matching strategy which is relatively error prone.

[findepi]

Now that we have table redirections it seems to me like we should never filter tables, and so these create table statements should always see the existing tables rather than relying on catching it with the exception code.

getTableHandle remains to throw for an unsupported table.
A known code for "table exists but is kind of unsupported" is a new quality introduced in this PR and necessary to handle CREATE TABLE failure when redirections are not enabled (configured.)

[mosabua]

I will assume that the label "no-release-notes" from @findepi supersedes the suggestion from @findinpath