Server refactoring and thread-based context

This PR contains to primary changes:

Stripping down of server component

As discussed in Slack, we ended up stripping down the Python server component of this demo. Specifically, this:

Removes the HTTP endpoints to query the bot
Removes Daily room creation
Removes Daily token retrieval and transcription start
Removes Daily API details being needed in the environment
Adds option to run a session bot either via a small web server or through the CLI (just getting the bot to join a specified room on the command line).

On the client, this:

Uses "app-message" events instead of HTTP requests to request summaries, custom queries, and clean transcripts.
Retrieves Daily meeting tokens in the session creation Next.js API route - this token is then used by the client to start transcription.
Adds copy and save buttons to clean transcripts and summaries.
Adds a form which requires a user creating a session to specify their own room URL, Daily API key, and OpenAI API key.

Experimental thread-based context

Uses the clean transcript for subsequent summary and custom queries (as opposed to the raw transcript that we get from Deepgram).
On the OpenAI side, this experiments with creating an Assistant and utilizing threads to query it for summaries. This is an experimental context approach that may change in the future.
The client no longer dictates when a clean transcript is generated. This is done every 30 seconds by the server, and the client can only request the latest available clean transcript for display to the user.

Does not contain

This PR does not contain error handling for app-message-based bot queries. For example, if a query currently fails the client will not know (whereas before, they'd receive an error code from the server). This will come in a followup PR.

This PR also does not contain sufficient tests, especially for the context logic. These should be added asap as a followup.

daily-demos / ai-meeting-assistant