Various doc tweaks

- "Optimized baseline entropy coding" = "Huffman table optimization"

  "Optimized baseline entropy coding" was meant to emphasize that the
  feature is only useful when generating baseline (single-scan lossy
  8-bit-per-sample Huffman-coded) JPEG images, because it is
  automatically enabled when generating Huffman-coded progressive
  (multi-scan), 12-bit-per-sample, and lossless JPEG images.  However,
  Huffman table optimization isn't actually an integral part of those
  non-baseline modes.  You can forego Huffman table optimization with
  12-bit data precision if you supply your own Huffman tables.  The spec
  doesn't require it with progressive or lossless mode, either, although
  our implementation does.  Furthermore, "baseline" describes more than
  just the type of entropy coding used.  It was incorrect to say that
  optimized "baseline" entropy coding is automatically enabled for
  Huffman-coded progressive, 12-bit-per-sample, and lossless JPEG
  images, since those are clearly not baseline images.

- "Progressive entropy coding" = "Progressive JPEG"

  "Progressive" describes more than just the type of entropy coding
  used.  (In fact, both Huffman-coded and arithmetic-coded images can be
  progressive.)

- Mention that TJPARAM_OPTIMIZE/TJ.PARAM_OPTIMIZE can be used with
  lossless transformation as well.

- General wordsmithing

- Formatting tweaks

java/org/libjpegturbo/turbojpeg/YUVImage.java

@@ -1,5 +1,5 @@
 /*
- * Copyright (C)2014, 2017, 2023 D. R. Commander.  All Rights Reserved.
+ * Copyright (C)2014, 2017, 2023-2024 D. R. Commander.  All Rights Reserved.
  * Copyright (C)2015 Viktor Szathmáry.  All Rights Reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -37,15 +37,15 @@ package org.libjpegturbo.turbojpeg;
  * serves as the destination image for YUV encode and decompress-to-YUV
  * operations and as the source image for compress-from-YUV and YUV decode
  * operations.
- * <p>
- * Technically, the JPEG format uses the YCbCr colorspace (which is technically
- * not a colorspace but a color transform), but per the convention of the
- * digital video community, the TurboJPEG API uses "YUV" to refer to an image
- * format consisting of Y, Cb, and Cr image planes.
- * <p>
- * Each plane is simply a 2D array of bytes, each byte representing the value
- * of one of the components (Y, Cb, or Cr) at a particular location in the
- * image.  The width and height of each plane are determined by the image
+ *
+ * <p>Technically, the JPEG format uses the YCbCr colorspace (which is
+ * technically not a colorspace but a color transform), but per the convention
+ * of the digital video community, the TurboJPEG API uses "YUV" to refer to an
+ * image format consisting of Y, Cb, and Cr image planes.
+ *
+ * <p>Each plane is simply a 2D array of bytes, each byte representing the
+ * value of one of the components (Y, Cb, or Cr) at a particular location in
+ * the image.  The width and height of each plane are determined by the image
  * width, height, and level of chrominance subsampling.  The luminance plane
  * width is the image width padded to the nearest multiple of the horizontal
  * subsampling factor (1 in the case of 4:4:4, grayscale, 4:4:0, or 4:4:1; 2 in
@@ -58,9 +58,9 @@ package org.libjpegturbo.turbojpeg;
  * the luminance plane width divided by the horizontal subsampling factor, and
  * the chrominance plane height is equal to the luminance plane height divided
  * by the vertical subsampling factor.
- * <p>
- * For example, if the source image is 35 x 35 pixels and 4:2:2 subsampling is
- * used, then the luminance plane would be 36 x 35 bytes, and each of the
+ *
+ * <p>For example, if the source image is 35 x 35 pixels and 4:2:2 subsampling
+ * is used, then the luminance plane would be 36 x 35 bytes, and each of the
  * chrominance planes would be 18 x 35 bytes.  If you specify a row alignment
  * of 4 bytes on top of this, then the luminance plane would be 36 x 35 bytes,
  * and each of the chrominance planes would be 20 x 35 bytes.