feature: send message to assistants and assistants respond to message

[multipletwigs]

Description of the pull request

1. This PR introduces the concept of Thread Runs where we allow assistants to read through a thread, and respond with a message based on the context provided by the thread.
2. Just like how OpenAI's assistant's playground work, you can run a thread without having human input.
3. To mimic sending messages to assistant, simply call the POST thread/:id/message endpoint to add the human message, followed by a call to POST thread/:id/run where the body is the assistant_id created by the user, in which a Thread Run happens.
4. POST thread/:id/run gets a response from the assistant, and saves it into redis.

How I came up with this

1. OpenAI provides several endpoints with regards to creating assistants and threads.
2. Observing the network tab when using the OpenAI Assistants playground shows that sending messages to assistants are really just appending the user message, and doing a thread run as two chained api calls.

Related issues

Closes #8 #9, and half of #17 where we can select the model wanted for the assistant

Other changes

1. Modified gpt4adapter to take in an instruction as part of system role which is initialised upon assistant creation.
2. Denormalised Role information for Messages as LLM should know what Role this message belongs to without having to query from userId.
3. Installed dayjs for more robust date related functionalities.

Testings done

1. Added an integration test under threadRun.test.ts that...

• Creates a human user.
• From the human user, create a Thread and an Assistant.
• From the human user, run the thread once, and verified that the last message entry is from an assistant role.
• Verified that the Assistant follows the initial instruction given when the human user creates the assistant.

Checklist

• I have written tests
• My code does not produce new errors
• I gave myself a code review before asking others.

[GuiBibeau]

should we plan a default if ever somebody does not specify a model? That's something we can eventually do from a UI standpoint also.

feel free to ignore, not blocking a merge

[multipletwigs]

I think from the UI standpoint we can do a default!