Publish as modular JAR(s) to Maven Central

首先检查当前的项目布局和构建配置，然后审查提议的 Maven 约定、模块拆分、module-info.java、JDK 11 编译器级别，以及移除对 jchardet 和 XOM 的支持。包结构、遗留文件、向后兼容性、评审预期和发布流程都需要维护者作出决定，之后才能认为实现已经完成。

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?