Fix setting iceberg table location on creation for REST/NESSIE catalog

[hantangwangd]

Description

Currently we ignore the specified table property location when creating tables on iceberg catalogs based on IcebergNativeMetadata, this will result in that the newly created table's location always using default values, regardless of whether a custom location is explicitly specified or not.

This behavior is somewhat unreasonable, as for catalogs that support specifying table locations on creation (like Rest and Nessie), the newly created table's location should be the specified path; while for catalogs that do not support specifying table locations on creation (like Hadoop), exceptions should be thrown directly.

This PR fix the above problem, pass the specified table location to Iceberg lib when creating tables on catalogs based on IcebergNativeMetadata .

Motivation and Context

Support specifying table location on creation for Iceberg connector on as many catalog types as possible.

Impact

Iceberg connector configured with REST and NESSIE catalogs now support specifying table location on creation.
Iceberg connector configured with HADOOP catalogs now fail directly when specifying table location on creation.

Test Plan

• Newly added test cases for creating iceberg table with custom location

Contributor checklist

• Please make sure your submission complies with our contributing guide, in particular code style and commit standards.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

== RELEASE NOTES ==

Iceberg Connector Changes
* Add support of specifying table location on creation for Iceberg connector when configured with ``REST`` and ``NESSIE``. :pr:`24218`

[kiersten-stokes]

This has always bothered me - LGTM with one NIT

[kiersten-stokes]

NIT: should we go with the fully qualified import here? (and I think for some instances of CatalogType.HIVE in the same file)

[hantangwangd]

Fixed!