Tasks API: Design and implement tasks data model in database #948

Design and implement the database-side data model for Tasks. The goal is to support the Tasks feature with a durable representation of tasks, agent-reported task states, and (a history of) workspace associations.

Goals:

• First-class Task records
  • Belong to an org and an owner
  • Can exist without any workspace
  • Carry user-provided inputs/parameters and minimal metadata for identification
• Workspace links (history)
  • Enforce at most one active workspace link per task at the DB layer
  • Persist a history of all workspace associations for a task (e.g. task "resumption" after workspace is gone)
  • There can be zero or one active link at a time
  • A link should be able to reference the relevant build and agent so we can fetch logs during startup.
• Decoupling from workspace lifecycle
  • The codersdk.WorkspaceStatus enum is huge, and Tasks brings its own requirements like:
    • Show build log during building
    • Show agent log during startup
    • Know when the task is fully prepared (ready)
    • (Future) pause/resume
  • Tasks care about workspace status to render e.g. build logs at the right time
  • Tasks care about agent lifecycle (starting, ready, etc) as these are queues for the UI to render logs or showing that a task is fully ready

Eventual goals:

• Task states (activity/history)
  • Persist a task activity state that reflects the agent's view of the task (e.g., working/idle/etc).
  • Currently implemented via workspace app statuses (which may be deprecated or removed in favor of task specific states)

Open questions:

• Exact task lifecycle/status taxonomy (names and transitions)
• Deprecation/migration path from workspace app statuses to task-specific states

References: #838, #898