Separate voice_settings from root-level parameters in API payload

Problem/Motivation

The `apply_text_normalization` parameter (and other root-level API parameters) are incorrectly being passed inside the `voice_settings` object instead of at the root level of the API payload. This violates the ElevenLabs API specification and causes the text normalization feature to not work properly, resulting in poor pronunciation in different ways (e.g., "2025 (Q1 2025)" ends up garbled).

Per the ElevenLabs API documentation (https://elevenlabs.io/docs/api-reference/text-to-speech/convert), there are 5 voice settings parameters (`stability`, `similarity_boost`, `style`, `speed`, `use_speaker_boost`) that belong in the `voice_settings` object, and 10 root-level parameters (`apply_text_normalization`, `apply_language_text_normalization`, `pronunciation_dictionary_locators`, `seed`, `previous_text`, `next_text`, `previous_request_ids`, `next_request_ids`, `use_pvc_as_ivc`, `language_code`) that should be at the root level of the payload.

Steps to reproduce

Use this Elevenlabs module to generate speech from text that includes the phrase "2025 (Q1 2025) " and notice how it ends up garbled.

Proposed resolution

Modify `ElevenLabsApiService::textToSpeech()` to properly separate voice settings parameters from root-level API parameters according to the ElevenLabs API specification. Only pass parameters where the module default differs from the API default to minimize payload size.

Update `ElevenlabsProvider::textToSpeech()` to pass configuration directly instead of wrapping it in a `voice_settings` array, allowing the API service to handle the parameter separation.

Remaining tasks

I'm submitting a merge request. It just needs a review. After applying it, apply_text_normalization will be correctly passed to the API (along with other root-level parameters) and text like "2025 (Q1 2025)" will now be converted to speech correctly.

UI changes

None

API changes

The `textToSpeech()` method signature remains unchanged, but the internal handling of the `$options` array parameter is modified to properly route parameters to their correct locations in the API payload.

Data model changes

None