Add bufplugin package

[emcfarlane]

This adds a new package, bufplugin, which implements types and functions for operating on Buf plugins. It is similar to the bufmodule package for modules.

Parsing of full names and refs has been split out into a separate package from bufmodule called bufparse. This exposes two types FullName and Ref which replace ModuleFullName and ModuleRef and is used by both. Methods ModuleFullName() ModuleFullName and ModuleRef() ModuleRef have been renamed to FullName() bufparse.FullName and Ref() bufparse.Ref.

The error type ParseError returned from Parse.* methods have been moved to the single type bufparse.ParseError updating the packages bufcas, bufmodule and bufplugin.

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Nov 4, 2024, 4:20 PM

[bufdev]

I thought this stuff was being pulled out to a common bufparse package? Also would likely result in some of errors.go being pulled out (and potentially other stuff).

[emcfarlane]

I did look at pulling it out into bufparse but reverted in 477557f. I noticed we already had another ParseError type in bufcas so thought copying was more consistent. Will refactor back out to a package.

[bufdev]

Assume this would be pulled out to a ParseFullName for example

[emcfarlane]

This has now been pulled out into bufparse.ParseFullName and returns a type of bufparse.FullName. Updated the PR docs.

[doriable]

Overall, this change seems very reasonable -- it's more of a refactor to unifying the types and then adding the plugin types. We should discuss whether it makes sense to have digest and commit as shared types instead also. There could even be an argument to be made for Key to be a single interface that bufmodule and bufplugin each implement with its own semantics (e.g. restrictions on digest types, etc.).