ATTACH 'arn:aws:s3tables:...' and infra for expanding to other resources

[carlopi]

Registers a pass-through:

class ArnStorageExtension : public StorageExtension {
public:
	ArnStorageExtension() {
		attach = ArnAttach;
		create_transaction_manager = ArnCreateTransactionManager;
	}
};

that will recognize paths-like strings like arn:aws:<service>:<region>:<AMI>:<type/<name>, and then either refuse them as not supported or redirect to the relevant attach.

Redirect is implemented only for arn:aws:s3tables:..., where it remaps to the iceberg-type attach on an ARN, but it's somewhat generalizable to other resources.

This PR will allow for:

LOAD aws;
--- possibly create credentials
ATTACH 'arn:aws:s3tables:us-east-1:259911478022:bucket/iceberg-on-the-browser' AS lake;
FROM lake.tpch10.customers;

and allow a path for other Catalog-shaped resources that have an ARN to be attached referencing the ARN. Once #162 lands, that would also be a prime addition to this surface.

A follow up duckdb/ducdkb side would be registering arn->aws remapping, allowing autoloading to happen, that makes so that if credentials are already on the user machine, the single statement version to also work:

ATTACH 'arn:aws:s3tables:us-east-1:259911478022:bucket/iceberg-on-the-browser' AS lake;

This is on top of #164, bumped to include the required duckdb/duckdb#23759

[carlopi]

Question from @Tmonster: what happens if I do:

ATTACH 'arn:aws:s3tables:us-east-1:259911478022:bucket/iceberg-on-the-browser' AS lake (OPT1, OPT2);

? How are those treaded / conflicts & co.

[carlopi]

Options are passed down correctly, with a throw on conflicts.

One question I had is whether there was a better than hand parsing the arn, and there is none in the AWS's SDK and non API to do so.
I have not researched third party libraries, but we might be better off doing this in a customized way.