Add user-facing docs for the new Task Loops feature

[ashb]

Task Loops, introduced in AIP-111, are a whole new way for dag authors
to thing Loops change how a Dag author thinks about repeating work, and
the change to implement it reaches storage, the scheduler, the Execution
API and the UI. Since all these changes are relatively large, it is
helpful before we introduct those that reviewers have a mental model
of what the behaviour should be, and the features we want to allow are.
Rather than explaining this just in PR messages or review threads, lets
add this as user facing docs, as most of that will be needed there too.

The new Loops doc covers how a loop decides whether to run another pass,
how a task reads the previous pass's result, what clearing part of a
loop does to the rest, and how loops interact with mapped tasks. At this
point/in this PR, nothing exists as code mind you.

The short "loop or mapped tasks" page is net-new, and is ther mostly
as a jumping off point for "here are the dynamic features you can build
your dag with".

This overview is also why "dynamic mapped tasks" is getting a name
change. Mapping is no longer the only way for a Dag's shape to depend on
data at runtime, and arguably, mapped tasks aren't really that "dynamic"
anymore. "Mapped tasks" is what the UI and the API already call the
result ("Clear All Mapped Tasks", MappedOperator), and it reads next to
"Loops" as the title of the page the overview links to. "Task mapping"
never appears in the UI.

However, please note that the rename is "soft" on purpose. The mapping
page keeps its file name and its dynamic-task-mapping label, and
the old name stays in its opening sentence so existing searches still
land. Provider docs link that page by path through intersphinx so
moving the file would break their builds until each one is updated. The
dynamic-task-mapping capability key that the language SDKs report is
an identifier rather than prose and is left alone.

The snippets are inline here because the example Dags that the guide
will include ship with the authoring API, and a file that calls
.loop() cannot be imported before .loop() exists. That change
replaces them with included copies that a test executes, so the
documented code cannot drift from the behaviour.

The placeholder newsfragment is also here because .loop() is a new
user-visible Dag authoring feature that ships through task-sdk with
airflow-core. It will grow and be adjusted by future PRs in this stack.

[ashb]

Turns out you can only have a stack targeting main. So I'll wait to create the rest of the stack until #74222 lands.

[TJaniF]

This looks great! Just had a few nits/suggestions and one question. :)