FR: Parameterized task labels.

TL;DR: Allow variable substitution in task `name` so that something like this works:
```
common: &common
name: "{bazel}_{platform}"

lts: <s
bazel: latest

rolling: &rolling
bazel: rolling

ubuntu: &ubuntu
platform: ubuntu1804
<<: *common

windows: &windows
platform: windows
<<: *common

tasks:
rolling_ubuntu:
<<: *ubuntu
<<: *rolling
rolling_windows:
<<: *windows
<<: *rolling
lts_ubuntu:
<<: *ubuntu
<<: *lts
lts_windows:
<<: *windows
<<: *lts
```

The task names should be precisely the names defined by the string, without adding the platform display label or the imported .yml file name.

Motivation:
- When trying to define CI runs for both LTS and rolling, you want the bazel version in the name to disambiguate tasks easily. Example: https://github.com/bazelbuild/rules_pkg/pull/430
- Most rule authors rarely care about the precise JDK running on each platform (the way the Bazel core project does). They care more about the bazel version and OS. Thus, that should not appended to the task name unless desired.

Difficulty: Minimal. A patch that mostly does it is:
```
$ diff bazelci.py ../continuous-integration/buildkite
921,930c921
< new_name = namespace
< if old_name:
< if old_name.find('{') >= 0: # }
< new_name = old_name.format(
< namespace = namespace,
< **task_config
< )
< else:
< new_name = "%s (%s)" % (namespace, old_name)
< task_config["name"] = new_name
---
> task_config["name"] = "%s (%s)" % (namespace, old_name) if old_name else namespace
```
I can send a complete PR if we like the idea.

Read bazelci.py around the task name construction shown in the issue, starting with the handling of old_name, namespace, and task_config. Verify the generated labels for the YAML examples, including LTS versus rolling and Ubuntu versus Windows; done means names use the requested parameter substitutions without automatically appending platform or imported-file labels.

Written by the indexing model from the issue text.