SQL UDF REST catalog write support (once standardized)

## Summary

This is a follow-up to #1360.

iceberg-go now has the foundation for SQL UDF catalog support:

- #1418 adds the spec-validated `udf` metadata model and metadata builder.
- #1432 adds the REST catalog read side for listing and loading functions.

The current Iceberg REST OpenAPI defines only the read-side function operations:

- `GET /v1/{prefix}/namespaces/{namespace}/functions`
- `GET /v1/{prefix}/namespaces/{namespace}/functions/{function}`

The OpenAPI does not currently define standardized function write routes or request/response contracts for operations such as create, replace/update, drop, or commit. The REST spec change that introduced list/load support was intentionally scoped as read-only Stage 1 and deferred function CRUD to a follow-up proposal: https://github.com/apache/iceberg/pull/15180.

The `udf` metadata builder can construct valid immutable metadata, but a REST client still needs a standardized catalog protocol for publishing that metadata and atomically changing the catalog's current metadata pointer. Until that protocol exists, iceberg-go should not introduce implementation-specific REST routes or wire models that may diverge from the eventual Iceberg contract.

## Desired outcome

Once the Apache Iceberg REST catalog specification defines function write operations, add the corresponding generic client support to iceberg-go using the standardized contracts.

The implementation should, as applicable to the final specification:

- expose write operations through an optional catalog capability interface, consistent with existing iceberg-go catalog patterns
- add the standardized endpoint constants and honor endpoint discovery through `ConfigResponse.endpoints`
- implement the exact request and response wire models from the REST OpenAPI
- use the existing `udf` metadata model and builder rather than introducing a second metadata representation
- preserve the specification's atomic metadata update and overload/version-history semantics
- map standardized errors for missing namespaces/functions, already-existing functions, conflicts, invalid requests, and unsupported operations
- implement any specified concurrency controls, preconditions, and idempotency behavior
- add unit coverage for successful writes, validation failures, error mapping, endpoint negotiation, concurrent/conflicting updates, and round-tripping written metadata through `LoadFunction`
- add documentation and examples for the supported catalog operations

The public Go API should be designed from the final standardized operations rather than assuming in advance that the REST surface will use a particular set of create/replace/drop methods.