No Response on Initial Message problem fixed and sound feature added

[amansoni7477030]

1. Fxed a major issue with responses, as defined in No Response on Initial Message Flowise#2291 and in issue No Response on Initial Message #158. Now, it will always show a response, even if the server is very slow with lower CPU and RAM. If the websocket takes time to connect and streaming is already over, it will directly show the result.
2. Added a new feature of sound: now users can add input and output sound effects for sending and receiving messages. Below are the parameters used:

sendMessageSound: true,
// sendSoundLocation: "send_message.mp3", // If not used, the default sound effect will play when sendMessageSound is true.
receiveMessageSound: true,
// receiveSoundLocation: "receive_message.mp3", // If not used, the default sound effect will play when receiveMessageSound is true.

[HenryHengZJ]

Now we store the base64 string of the sound, it makes the web.js becomes extremely long:

perhaps we could store it to like raw.github or some other storage, instead of local

[amansoni7477030]

Now we store the base64 string of the sound, it makes the web.js becomes extremely long:

perhaps we could store it to like raw.github or some other storage, instead of local

@HenryHengZJ Initially, I used GitHub Raw, which worked well. I also considered and decided that using a CDN is the best option, although both are sometimes slow. That's why I switched to using local storage. As you suggested, I've updated the code so that it now defaults to using the CDN. If needed, you can modify the CDN link or change it to the GitHub Raw link.