Перенос основной логики конструктора GigaChatApi в автоконфигурацию

Сейчас в конструкторе GigaChatApi происходит слишком много всего, после добавления ApiKey количество аргументов в конструкторе станет уже не очень красивым, а при развитии Api их будет все больше, если брать для примера тот же OpenAiChatApi.

Предлагаю вынести логику сборки из конструктора в автоконфигурацию:
1. Бин ApiKey для предоставления ключа, начали в #66
2. Бин SSLFactory для поддержки unsafe-ssl
3. Бин HttpClient, который соберется c SSLFactory и конфигом таймаута
4. Бин RestClient, который соберется из HttpClient + ApiKey
5. Бин ResponseErrorHandler, который поможет правильно собрать RestClient и WebClient

Все бины должны быть с аннотациями, которые позволят бесшовно работать с Spring 7 и Spring-boot 4, автоконфигурация должна быть хорошо задокументирована и предоставлять примеры как переопределить любые компоненты и под какие цели есть смысл это делать.

Спорные вопросы:
1. По-хорошему JdkClientHttpRequestFactory и JdkClientHttpConnector также следует объявить бинами, однако Spring-boot подтянет их и сделает глобальными для всех RestClient и WebClient, что не очень хорошо, а обертки-провайдеры делать не очень хочется 🥲

@linarkou что думаешь по этому поводу?

Проблема на лицо:
https://github.com/ai-forever/spring-ai-gigachat/blob/e5e70deb38f03f8905d88a3b48026ccd50f8b395/spring-ai-gigachat/src/main/java/chat/giga/springai/api/chat/GigaChatApi.java#L79-L119