refactor: switch to standard Go vendoring for cross-distro packaging

[pcdubs]

Replace go-vendor-tools with standard Go module vendoring to support
building on both Fedora and CentOS/RHEL with a single spec file.

Changes:

• Commit vendor/ directory to git (998 vendored dependency files)
• Include vendor/ directory in Source0 tarball
• Set GO111MODULE=on and GOFLAGS=-mod=vendor for build and test phases
• Remove go-vendor-tools dependency from spec and Packit config
• Add vendor/modules.txt to %license for bundled dependency tracking
• Add testdata files (dc.bin, mfg_key.pem, ov.pem) to vendored go-fdo
  package required by //go:embed directives for build-time compilation

CI workflow updates:

• Exclude vendor/ from codespell spell-check to avoid false positives
  in third-party dependencies
• Exclude vendor/ from DevSkim security scanner to prevent flagging
  vendored code issues
• Disable Go dependency caching in setup-go action since vendored
  dependencies don't require go.sum

This approach follows the standard pattern used by major Go packages
in Fedora and ensures compatibility across distributions.

[pcdubs]

/packit rebuild

[github-advanced-security]

devskim found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[ben-krieger]

Personally, I hate vendoring. Before Go modules, it was the best way (at least before dep), but now it's a huge pain.

1. It requires devs to remember an extra step before pushing
2. It significantly slows down git clones and gets much worse over time with no great ways to fix
3. It makes GitHub reviews much worse for humans

On the plus side, it makes building with Nix easier.

At a bare minimum, the gitattributes must be changed so GitHub doesn't show vendored files in the diffs. If review pages start failing to load due to diff size (especially on mobile), it will be hard for me to help.

[pcdubs]

Personally, I hate vendoring. Before Go modules, it was the best way (at least before dep), but now it's a huge pain

I looked at different options without using EPEL and this seems to be a standard practice used by other projects for supporting both Fedora and Centos in a single spec file.

1. It requires devs to remember an extra step before pushing

The extra step should only be needed when dependencies are added or updated. We can mitigate this by adding a pre-commit hook that validates vendor/ is in sync and/or a CI check that will fail if not.

2. It significantly slows down git clones and gets much worse over time with no great ways to fix

A definite drawback. I think cross distro compatibility is worth it, but I'm happy to explore other options if you have suggestions.

3. It makes GitHub reviews much worse for humans

I've added gitattributes to exclude vendor files from diffs, which should help the review experience. Thanks for the suggestion.

[mmartinv]

I think the only thing I am missing is the replacement of the licensing macros, maybe we can use the tools externally to generate the files and include them in the spec.

[mmartinv]

Shouldn't we replace this with %go_generate_buildrequires from the go-rpm-macros package? not sure if that would work though

[mmartinv]

Although we are not going to use the go-vendor-tools.toml file from within the spec file, it might worth it to maintain it in the sources so it's possible to generate the vendor tarball externally with go-vendor-tools. ??

[mmartinv]

The problem is the spec file depending on go-vendor-tools, not its use in the Makefile. We can keep the current vendor tarball generation I believe