Implement synchronous SDK client

There might be specific use cases, when making use of the synchronous client yields a better performance than with the async one.
For example, when building the ultra-low latency system, with threads pinned to the cores - the async client is pretty much useless in such a design and will result in worse performance than the sync one.

The sync client could be kept behind a specific feature flag, which would drop the existing Tokio reference, and use the standard TCP network library (along with the blocking client for `reqwest` crate). The existing `Client` trait could have all the methods defined as the synchronous ones. The other solution, would be to introduce some sort of `SyncClient` trait, as an addition to the already existing asynchronous version.

It would also be beneficial, to provide the similar high-level builders for `IggyProducer`, IggyConsumer` etc. to provide a great developer experience.

This is certainly a big feature, and it's worth discussing how to best tackle this.

Start by reading the existing Client trait and asynchronous client to understand the current SDK surface and Tokio dependency. Compare the proposed feature-flagged synchronous client using standard TCP and reqwest's blocking client, then determine the scope of synchronous high-level builders; done requires an agreed design and a complete synchronous API.

Written by the indexing model from the issue text.