[GitHub Target] Feature proposal: a templated list of tags to push

[tonyo]

We (the Web Backend SDK team) can implement on this, just want to get a 👍 before starting.

Context: Releasing Golang Submodules

A Go module is a collection of Go packages that are distributed as one unit.
Go also supports submodules (or "nested modules"): basically, they are Go modules that live in the same repository, but in different directories, each submodule having its own go.mod file in its root. The top-most project directory in this case becomes the root module.

Example: https://github.com/open-telemetry/opentelemetry-go is a Go module that has submodules trace, sdk, schema, and some others.

sentry-go will add a few submodules in the near future (e.g. our OpenTelemetry integration will live in a new submodule).

Now, when releasing a new version of a submodule (which can be released independently from the root module, but we're not going to do that for sentry-go for now), we have to tag the repository with "personalized" Git tag. So e.g. when we release v1.2.3 of submodule otel in sentry-go, we'll have to push the Git tag that would look like otel/v1.2.3. Each submodule will get its own tag in the form of {MODULE_PREFIX}/{VERSION}.

Problem

When making a new release for a Go project with a bunch of submodules, we need to push several Git tags to GitHub.
Craft (or specifically, the GitHub target) doesn't support pushing more than one tag at the moment

Proposed Solution

Add a new option to the github target: createTags (or just tags, name TBD) of type string[]. It's essentially a more powerful extension to the tagPrefix parameter that allows to specify a list of tags that have to be pushed by the target.
It will also support basic templating, so that e.g. the version to-be-released is a template variable that can be used.

For sentry-go the config can look something like this:

targets:
  - name: github
    createTags:
      - "v{VERSION}"      # Root module
      - "otel/v{VERSION}" # Nested module

[BYK]

I'm not on the team but I think this is a pretty good idea ☺️

Suggestions:

1. Just name it tags
2. Deprecate the tagPrefix config and roll it into this one
3. Document the variables available to basic templating very well

[tonyo]

Thanks @BYK 👍

@asottile-sentry asked whether we already can do the same thing just using multiple github targets with different tagPrefix.
I double-checked, and the problem right now is that every github target basically creates a full-fledged GitHub release that is visible on the Releases page, and we don't really need/want that for Go (just tags).

So the refined suggestion looks like this:

1. No tags attribute, tagPrefix is empty or present => legacy behavior, print a warning that tagPrefix is deprecated.
2. Both tags and tagPrefix are non-empty => raise an error, exit.
3. tags is present, tagPrefix empty => new behavior, and the first tag from the list is used for creating the GitHub release.

[BYK]

Sounds good to me. An alternative might be to allow tagPrefix to be an array of strings (new behavior) or just a string. This is a bit "dirty" but allows for easier configuration and avoids any config migrations.

[tonyo]

Gave it a bit more thought and decided not to implement this proposal right now: the use case is not strong enough to spend days/weeks working on the feature and then deprecating/migrating the existing apps.
Here's a smaller change that will cover our Go case: #447