feat: allow source patches to be placed in user-defined output groups

[kormide]

I don't think it's enough to put patches for source files into a single output group. In a build graph there may be different categories of patches and how they're dealt with. For example, you might want patches for a vendored bundle to be automatically applied on CI, but for a snapshot test you would want someone to carefully review the diff before committing.

This adds a mechanism to differentiate those categories via custom output groups. I don't think diff.bzl should go as far as defining what those categories are, so this seems like the appropriate level for customization.

[alexeagle]

Sorry for delay!

Yes, my initial thinking was the simplest answer is for the .gitattributes file to indicate generated files, and the default setting most users would want is "generated code is always replaced without review".

Perhaps that solves the 80% case but it does make sense to me to have a simple way for users to define other semantics.

[kormide]

Sorry for delay!

Yes, my initial thinking was the simplest answer is for the .gitattributes file to indicate generated files, and the default setting most users would want is "generated code is always replaced without review".

Perhaps that solves the 80% case but it does make sense to me to have a simple way for users to define other semantics.

Deriving from .gitattributes would be nice, but how would you map from a patch in the output tree to a file in the source tree? You'd have the read the contents of every patch to see what source files they touch, unless you rely on some consistent naming scheme for the patch file.

I'll change source_patch_extra_output_groups to just source_patch_output_groups with a default of ["diff_bzl__patch"]. Seems a bit cleaner.