Publish as modular JAR(s) to Maven Central

Start by reviewing the current project layout and build configuration, then examine the proposed Maven conventions, module split, module-info.java, JDK 11 compiler level, and removal of jchardet and XOM support. The package structure, legacy files, backward compatibility, review expectations, and release process all need maintainer decisions before implementation can be considered done.

Motivation:

• it's been since 2012 since the last release (there are more recent releases of the nu-validator branch, but that distribution isn’t actually intended to be used outside the context of the HTML checker)
• this is a foundational library, so any library/application that uses it and wants to migrate to Java modules, relies on this library being modularized (though automatic modules might help, they have their limits)

I'm willing to help by providing PRs such as:

• adapt the folder layout to Maven conventions
• split the project into multiple Maven modules as needed (since it's a lot easier if there's a 1-on-1 mapping between Maven and Java modules)
• make the Maven build work with a JDK 11+ release. In fact, such a JDK would be required in order to be able to compile the module-info.java file, so I'd like to upgrade the compiler level to 11 as well (the code can stay on the 1.5 syntactic level. I'm not planning to make any code changes, apart from package declarations and import statements)
• remove jchardet and XOM support: jchardet is an unmaintained library, and I don't see how XOM will be able to modularize itself any time soon, given that it relies on the xml-apis:xml-apis Maven artifact, and thus has a "split packages" issue

However, I have a few questions:

• first and foremost: if I provide PRs such as the above, will they be reviewed & accepted, and will a new release be published once modularization is done?
• there's a lot of files that are apparently unmaintained. Why aren't these deleted? It would help a lot if any legacy files would be deleted before starting
• there's 3 packages: encodings, htmlparser, saxtree. I understand why encodings is a separate package outside of htmlparser, but why is this also the case for saxtree? It's relied upon by the htmlparser package, and I don't readily see why someone using this library would use its classes directly
• following from my previous question: would it be acceptable to move saxtree into a package under the htmlparser package? Or is this package used directly by users of this library, and would changing the package name be a problem w.r.t. backward compatibility?

@hsivonen @sideshowbarker what are your thoughts on this?