proposal: compress/lzw: freeze lzw package

[dsnet]

In the spirit of #15557, I propose freezing the compress/lzw package such that we no longer accept new features or optimizations. Only bug fixes would be accepted.

My rationale for freezing is:

• It was originally added to support image/gif and is primarily used in the GIF, PDF, and TIFF formats and probably should have been an internal package.
• To my knowledge, it does not have a standardized specification. Thus, the exact format actually slightly differs even between GIF and TIFF (see Proposal: compress/lzw: extend package for correctly handling tiff files and pdf LZWDecode filters  #25409).
• It is very seldom used (100x fewer than gzip):
  • compress/lzw: 78 imports
  • compress/bzip2: 845 imports
  • compress/flate: 1338 imports
  • compress/gzip: 10327 imports
• The package is difficult to use as the exact options used when writing are important for how to semantically interpret the format when reading.

Those who desire new features are welcome to fork the package and make modifications as fit.

[ghost]

Why disallow optimizations though? The rationale evades this point.

[dsnet]

My motivation for disallowing optimizations is that experience shows that optimizations have an unfortunate side-effect of often introducing bugs. Additionally, optimizations generally increase the complexity of a package, not decrease it.

[hhrutter]

As noted in #25409 compress/lzw does not work correctly with PDFs.

[rsc]

Dup of #25409. Completely different suggestion but clearly just the other side of the coin. Resolving #25409 will resolve this, one way or another. No need to keep both open.