First implementation of tasks

[JoannaaKL]

PR Guideline

Typically, PRs should consist of a single commit, and so should generally follow
the rules for Go commit messages.
First implementation of experimental Tasks feature.
Issue link

You must follow the form:

net/http: handle foo when bar

[longer description here in the body]

Fixes #12345

Notably, for the subject (the first line of description):

• the name of the package affected by the change goes before the colon
• the part after the colon uses the verb tense + phrase that completes the blank in, “this change modifies this package to ___________”
• the verb after the colon is lowercase
• there is no trailing period
• it should be kept as short as possible

Additionally:

• Markdown is allowed.
• For a pervasive change, use "all" in the title instead of a package name.
• The PR description should provide context (why this change?) and describe the changes
  at a high level. Changes that are obvious from the diffs don't need to be mentioned.

[jba]

Please delete the guidelines and write a proper commit message. Link to the part of the spec that defines tasks.

[jba]

Also link to our issue about tasks.

[jba]

I just skimmed the spec. It is huge. I think we should implement it in multiple PRs. Let's start with the relatively easy stuff. How about a PR for capabilities first? And maybe one for the task data structure and related code, like generating the task ID?

[jba]

I don't quite understand how calling a tool with a task works. It looks like the tool itself doesn't have to know about tasks. Where is the code that returns the task result immediately and then handles task lifetime management?

I think everything else is pretty straightforward, but this part of the design needs to be discussed on our tasks issue.