Audio transcription support

[andrewfrench]

• Introduces an AudioLoader, responsible for producing an AudioArtifact from binary audio data
• Add AudioTranscriptionTask, accepting an AudioArtifact and responding with a TextArtifact containing the transcribed text
• Add AudioTranscriptionClient allowing an Agent to generate a transcription from audio in memory or on the filesystem
• Add OpenAiAudioTranscriptionDriver to support integration with OpenAI's speech-to-text models
• Update structure configs to reference either OpenAiAudioTranscriptionDriver or DummyAudioTranscriptionDriver
• Add tests and documentation for added constructs

---

📚 Documentation preview 📚: https://griptape--781.org.readthedocs.build//781/

[codecov]

Codecov Report

Attention: Patch coverage is 82.31707% with 29 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...o_transcription/base_audio_transcription_driver.py	51.72%	12 Missing and 2 partials ⚠️
griptape/tasks/audio_transcription_task.py	77.14%	5 Missing and 3 partials ⚠️
griptape/tools/audio_transcription_client/tool.py	89.65%	1 Missing and 2 partials ⚠️
...transcription/openai_audio_transcription_driver.py	90.47%	1 Missing and 1 partial ⚠️
..._transcription/dummy_audio_transcription_driver.py	90.00%	1 Missing ⚠️
...iptape/engines/audio/audio_transcription_engine.py	87.50%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[collindutter]

Outside the scope of this PR but I'm starting to doubt our pattern of creating Engines that are just thin wrappers over Drivers. Engines should augment 1 or more Drivers for a specific use-case that a single Driver cannot do on its' own.

What do you think?
CC @vasinov

[andrewfrench]

I strongly agree, this layer is way too thin, but I also did not want to create a weird single audio-to-text modality that breaks our established pattern. Optimistically, they're a layer where we can add additional functionality. For now, they're mostly an additional initialization step.

[collindutter]

Nice work, just naming comments

[collindutter]

Should we name these Drivers BaseSpeechToTextDriver for consistency with the inverse Drivers?

[andrewfrench]

I think I've steered a bit too far in the direction of naming drivers based on their artifact interfaces. I think the specificity of this name is helpful, what do you think about adding a similarly specific name to the BaseTextToSpeechDriver? BaseSpeechGenerationDriver?

[collindutter]

Yeah thinking about it more I think this current convention is the more "correct" one.

Down to do a rename of BaseTextToSpeechDriver (though maybe in a separate PR), what do you think about BaseAudioGenerationDriver? This may extend beyond speech in the future?

[collindutter]

Great work!