Pass in custom conversation ID from caller application for chatflows

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] Please do not modify this template :) and fill in all the required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

Currently, when another application (caller application) invokes a dify chatflow, it is unable to pass an existing conversation ID that was already created by the caller application to Dify. Dify only accepts a blank conversation ID or a conversation ID that exists in Dify.

If Dify is able to accept conversation ID from another system:
1. Caller Application does not have to map its own conversation ID with Dify's conversation ID, both will be the same
2. Tracing will be easier as the same conversation ID is passed from end to end.

### 2. Additional context or comments

Expected behaviour:

When blank conversation_id is passed --> dify create new conversation ID

When existing conversation_id is passed --> dify use conversation ID to find existing chat history and continue chat

When new conversation_id is passed --> dify use caller application's conversation ID to start a new chat

### 3. Can you help us with this feature?

- [ ] I am interested in contributing to this feature.

Start by locating the chatflow API entry point that handles conversation_id and the code that loads or creates conversation history. Check how blank, existing, and caller-supplied new IDs are currently handled, then add coverage showing the three expected behaviors and run the relevant chatflow API tests.

Written by the indexing model from the issue text.