JavaDoc: try to fix syntax issues

The maven-javadoc-plugin is confused by some of our (probably malformed)
JavaDoc syntax, see `mvn package` output on JDK 17:

```
/home/runner/work/ks-java-runtime-test/ks-java-runtime-test/src/main/java/io/kaitai/struct/ByteBufferKaitaiStream.java:109: warning: empty <p> tag
     * <p>
       ^
/home/runner/work/ks-java-runtime-test/ks-java-runtime-test/src/main/java/io/kaitai/struct/ByteBufferKaitaiStream.java:117: error: unexpected end tag: </p>
     * </p>
       ^
```

This `error: unexpected end tag` even prevents `mvn package` from succeeding.

Author: generalmimon

src/main/java/io/kaitai/struct/ByteBufferKaitaiStream.java

@@ -86,14 +86,13 @@ public ByteBufferKaitaiStream(ByteBuffer buffer) {
      * which the associated type was parsed, because the underlying {@link ByteBuffer} might
      * contain the data of all parent types and such as well and not only the one the caller is
      * actually interested in.
-     * </p>
      * <p>
      * The returned {@link ByteBuffer} is always rewinded to position 0, because this stream was
      * most likely used to parse a type already, in which case the former position would have been
      * at the end of the buffer. Such a position doesn't help a common reading user much and that
      * fact can easily be forgotten, repositioning to another index than the start is pretty easy
      * as well. Rewinding/repositioning doesn't even harm performance in any way.
-     * </p>
+     *
      * @return read-only {@link ByteBuffer} to access raw data for the associated type.
      */
     public ByteBuffer asRoBuffer() {
@@ -114,22 +113,19 @@ public ByteBuffer asRoBuffer() {
      * references to it, which breaks all subsequent <code>read..</code> methods with
      * {@link NullPointerException}. Afterwards, a call to {@link System#gc()} will
      * typically release the mmap, if garbage collection will be triggered.
-     * </p>
      * <p>
      * There is a <a href="https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4724038">
      * JDK-4724038 request for adding unmap method</a> filed at Java bugtracker since 2002,
      * but as of 2018, it is still unresolved.
-     * </p>
      * <p>
      * A couple of unsafe approaches (such as using JNI, or using reflection to invoke JVM
      * internal APIs) have been suggested and used with some success, but these are either
      * unportable or dangerous (may crash JVM), so we're not using them in this general
      * purpose code.
-     * </p>
      * <p>
      * For more examples and suggestions, see:
-     * https://stackoverflow.com/questions/2972986/how-to-unmap-a-file-from-memory-mapped-using-filechannel-in-java
-     * </p>
+     * <a href="https://stackoverflow.com/questions/2972986/how-to-unmap-a-file-from-memory-mapped-using-filechannel-in-java">How to unmap a file from memory mapped using FileChannel in java?</a>
+     *
      * @throws IOException if FileChannel can't be closed
      */
     @Override