Add Swift SDK for Apache Iggy

### Description

Build and maintain an official Swift SDK for Apache Iggy, providing an idiomatic Swift API for producing and consuming messages and managing Iggy resources.

The SDK should follow the capabilities and conventions of the existing Iggy SDKs while embracing modern Swift features such as structured concurrency, async/await, strong typing, and Swift Package Manager.

The implementation should include the SDK itself, automated tests, examples, CI integration, package distribution, and complete documentation on the Apache Iggy website.

Motivation
----

Apache Iggy aims to provide a strong developer experience across programming languages and application environments.

Today, Iggy provides SDKs for Rust, Python, Java, Go, Node.js, C#, C++, and PHP. Adding Swift would expand Iggy’s ecosystem into an important developer community that is currently underserved by streaming infrastructure libraries.

Swift has also evolved beyond application development into a general-purpose language increasingly suitable for:

* server-side applications and services;
* distributed systems;
* high-performance networking;
* systems programming;
* edge applications;
* real-time applications;
* applications spanning clients, edge infrastructure, and backend services.

A native Swift SDK would allow Swift developers to interact directly with Iggy without introducing Java, JVM, or other language/runtime dependencies into their applications.

There is also a particularly natural architectural fit between Swift and Iggy. Both ecosystems emphasize performance, memory safety, predictable resource usage, concurrency, and modern developer ergonomics.

The SDK could make Iggy especially useful for Swift applications that need durable, real-time event streams between devices, services, and backend infrastructure.

Examples include:

* application telemetry and event ingestion;
* real-time application state and event synchronization;
* backend services written in Swift;
* edge-to-cloud streaming;
* observability pipelines;
* AI/ML event and inference pipelines;
* durable event streams for agents and other asynchronous applications.

Most importantly, Swift support strengthens Iggy’s goal of making high-performance streaming infrastructure accessible through the language and development environment that developers already use.

### Affected area / component

_No response_

### Proposed solution

Developer experience
-----
The Swift SDK should follow established Swift conventions wherever possible.

In particular:

* Swift Package Manager should be the primary package mechanism;
* public APIs should use idiomatic Swift naming;
* asynchronous network operations should use async/await;
* APIs should be strongly typed rather than relying heavily on strings;
* errors should map into meaningful Swift error types;
* resource ownership and connection lifecycle should be explicit;
* documentation should work well with Swift tooling;
* the SDK should minimize external runtime dependencies.

Transport
-----
The first implementation should prioritize a reliable native transport and clean architecture over supporting every Iggy transport immediately.

Phase 1

Implement:

* TCP
* TLS

using the Iggy binary protocol.

The transport abstraction should be designed so additional transports can be introduced without changing the public client API.

Future

Evaluate support for:

* QUIC
* HTTP
* WebSocket

The long-term goal should be alignment with Iggy’s multi-protocol developer experience.

### Alternatives considered

_No response_

### Contribution

- [ ] I'm willing to submit a pull request to implement this feature

### Good first issue

- [ ] I think this could be a good first issue for a new contributor