Refactor error handling for streaming chat flow

[nomisRev]

Closes #113

• Removed the Error type from StreamingChatLanguageModelReply and its usage. Currently the error was being emitted twice. Once as an exception, and once as data. We should avoid emitting an event twice, since it only occurs once. It's possible for the user to manually transform the exception into a value using catch { emit(...) } as demonstrated in my other PR. Alternatively we can keep StreamingChatLanguageModelReply.Error but not re-emit again on close(throwable). This is a design decision that needs to be made. I don't have a strong preference to be honest, one or the other is fine. You can go back and forth by using catch or throw.
• Enforces unbounded channel buffer to avoid dropping messages

[kpavlov]

Tho idea behind emitting error as data was to carry some error details from LLM error response, so it is not an erroneous response per se, but an expected LLM reply.
But the specific exception class with LLM result make sense too, let me look at it one more time

[nomisRev]

I don't have a strong preference to be honest, one or the other is fine. You can go back and forth by using catch or throw.

Like I said I think either is fine, in the current scenario with both Error and close(error) it requires the user to handle it twice both the error value, and the actual exception. So I would opt for one or the other, I felt that lifting the "error" into the error path from Flow would make it easier to work with since then you can rely on the existing KotlinX Flow operators to handle any exceptions, or build retry flows, etc. With Error as a value catch, and retry are useless for error handling.

[kpavlov]

I opened another PR #178 to remove the StreamingChatLanguageModelReply.Error due to the conflict