Add linter to check for keywords in the package name

[bufdev]

Re: #265.

[codecov-io]

Codecov Report

Merging #281 into dev will increase coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##              dev     #281      +/-   ##
==========================================
+ Coverage   72.15%   72.22%   +0.06%     
==========================================
  Files         120      121       +1     
  Lines        5413     5425      +12     
==========================================
+ Hits         3906     3918      +12     
  Misses       1135     1135              
  Partials      372      372

Impacted Files	Coverage Δ
internal/lint/lint.go	79.2% <ø> (ø)	⬆️
internal/lint/check_package_no_keywords.go	100% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 99cbc87...6c7a321. Read the comment docs.

[scooter-dangle]

@peter-edge, had you considered adding a larger catalog of keywords to the lint? We recently had an issue where some FieldOptions that were used to generate supplemental deserialization code for a Go application had a field added called default without realizing that it would break the code generated for a downstream Java application managed by a different team.

We're planning to add checks in CI against the keyword lists for Java, C, C++, Go, and JavaScript. We also use Rust and Python, but Rust's recent addition of 'raw identifiers' lets it bypass the issue, and Python has a workaround using getattr (although I don't know whether that's considered ergonomic).

Of course, the trade-off is the linter having to enumerate many languages' keywords, which might be an unjustifiable maintenance burden.

---

UPDATE: Realized I neglected to ask if you had also considered keyword checks for fields in addition to the package name.

[bufdev]

I don't think we're going to extend this - the list would get too exhaustive. The current keyword set is meant to cover the most common cases, and as you mentioned, maintenance would be difficult. Additionally, we'd want such a linter to be part of a lint group, but adding linters (or keywords to the existing keyword linting) would be a breaking change.