Explore options to allow better customization of changesets in campaign spec

[mrnugget]

After writing RFC 265: Multiple changesets per repository and implementing one of two options in https://github.com/sourcegraph/sourcegraph/pull/16235 we still think that there's room for improvement in the way we

1. still miss an easy way to say: "create a changeset by creating changes in subdirectory A, B, C", see RFC 265)
2. don't have a way to easily customize changesets per repository: while we do allow setting published per repository, using the syntax for more than one field (say: branch, title, published) becomes quite noisy
3. don't have a way to easily set additional options per repository (see https://github.com/sourcegraph/sourcegraph/issues/16170)

This ticket should represent a spike to possible ways to restructure our campaign spec to make these things easier.

While talking about RFC 265 we realised that something's not quite right with our campaign spec structure and is standing in our way, so it makes sense to (time boxed) take a step back and, with all the knowledge about use cases we have right now, ask ourselves:

"What would a newly designed campaign spec look like that covers all of these use cases now?"

[mrnugget]

Exploration lead to prototype lead to implementation of dynamic changesetTemplate that's now in src-cli 3.24: sourcegraph/src-cli#424 (docs here: https://github.com/sourcegraph/sourcegraph/pull/17286)

The ticket was originally about more than this, but I'm closing it and will create a second one for the monorepo ideas we explored in our mob programming session.