Publish as modular JAR(s) to Maven Central

Inizia esaminando l’attuale struttura del progetto e la configurazione della build, quindi analizza le convenzioni Maven proposte, la suddivisione in moduli, module-info.java, il livello di compilazione JDK 11 e la rimozione del supporto a jchardet e XOM. La struttura dei package, i file legacy, la compatibilità all’indietro, le aspettative per la review e il processo di release richiedono tutti decisioni da parte dei maintainer prima che l’implementazione possa essere considerata completata.

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?