JtR next generation

While I'm not sure we'll ever actually manage to give birth to the "next generation" re-write of JtR, I thought we should at least have an issue here for brainstorming. Here's some of my thoughts quoted (and edited) from some other place nearby:

We'd do a total re-write but heavily re-use existing code (after careful considerations on a case-by-case basis). We'd not add a single line of code until (re-)defining lots of things, like code style (tho' actually the code style could be not to have one [except we'd mostly keep the current one for core, as in non-plugs]), plug-in interfaces (we should have mode plugs as well), source tree structure and so on.

Some must-haves (IMHO):

• All formats (except, say, -stdout) are plug-ins. We should strive to make the -stdout option as close to just any format as possible, from a code point of view.
• All modes (except, say, -stdin) are plug-ins.
• Ditch OpenSSL in favor of own code that can be more or less optimised (first prio is merely to have it working at all, performance isn't a priority until near a release).
• Candidate strings should be UTF-32 and/or UTF-8-32 all the way from generation (or reading from a file) to set_key(). Perhaps also (in lots of places but not everywhere) use a "pascal string" struct for strings in many parts of core.
• The use of threads (OpenMP or not) should be carefully planned so modes can use it where more beneficial than in the format.
• The core should obviously be written with node/fork/MPI in mind as well - including the option to split a job by salts as opposed to by candidates.
• New format interface(s) should be very carefully considered. This includes OpenCL/FPGA/other interfaces (eg. all main OpenCL kernels should have the same interface).
• On-device mask mode should be much easier to implement. Unified interfaces, shared CPU code, shared GPU code.
• An OpenCL format plugin (for example) should ideally not contain a single line of OpenCL code. Maybe we should also ditch the idea of having separate source files for CPU/OpenCL/ZTEX and so on - instead use a single one, calling abstraction layers in core for the non-CPU stuff.

Optional features:

• I came up with this idea recently but am not sure it with fly: We could try making some compatibility layer for using legacy plugin formats as-is. That way we con't need to upgrade all 321 plugins at once (we might even opt to never fix some of the most obscure).
• Re-write dynamic mode from scratch (using only the "dynamic compiler" mode, nothing else) and add OpenCL support for it.

I think the concept of "format tags" and aliases should be a core thing.

No files, tests, or entry points are named; the issue is a brainstorming thread for a broad JtR rewrite. Start by reviewing the existing core, format and mode plugin architecture, then define a scoped proposal with specific interfaces and validation criteria before attempting implementation.