Build a "debug" RPM for the Pelican client

[brianaydemir]

The goal of this PR is to ensure that Pelican's release process yields an RPM (yes, specifically an RPM) whose pelican binary includes sufficient information to be run successfully under a debugger, such as Delve.

---

Some notes about the changes here:

• I am taking advantage of YAML "anchors" and "aliases" to avoid duplicating raw YAML text. Admittedly, this depends on support for merge keys, but I've yet to encounter a YAML parser that behaves in an unexpected manner when presented with such.

• I've edited some of the lists in .goreleaser.yml so that the id key appears towards the top of each list element. It would seem that GoReleaser requires that these keys be unique, so burying them in the depths of a list element feels unhelpful.

• GoReleaser would seem to make it all-but-impossible to specify that the "debug" RPM provides a specific version of "pelican". While not ideal, I've decided that the simplest solution for the wider ecosystem is to claim that the debug RPM provides pelican, and leave it to end-users/consumers to sort out version constraints.

[timtheisen]

@brianhlin Do you want the 7.16.1 client on CHTC? Or should this be targetted for 7.15?

[brianhlin]

@timtheisen we need a 7.15.x client since we have two outstanding caches on 7.15

[timtheisen]

This pull request is against main, which implies 7.16. @brianaydemir probably needs to make a new PR against a 7.15 branch.

[brianaydemir]

PR's against main are for the next release — in this case 7.17.

I don't know the exact process for how these things get back ported. @jhiemstrawisc?

We could also probably use some sort of plan for keeping that hard-coded version in provides up-to-date(-ish).

[jhiemstrawisc]

If you want this backported, add the create-patch label and ping whomever the release manager is for the backport series (me for 7.16). I'll add this to the patch I plan to create later today.