Consider changing algorithm_name on the fly

In https://github.com/magnumripper/JohnTheRipper/pull/2525#issuecomment-298842256 @solardiz wrote:

On Wed, May 03, 2017 at 12:32:17AM -0700, magnum wrote:

Depending on salt type, we either do SHA-256 (with AVX2) or scrypt (without), so no matter how we put it this algo string will be ambiguous. Same problem with many other formats.

Maybe include "... or ..." in the algorithm string?

(When all loaded salts are of the same type, we could also patch the string at runtime to be specific, but that's tricky and probably not worth the bother. We could even patch the "or" to "and" when we know that we have salts of both types, but that's similarly tricky, especially if we want to consider only the uncracked hashes.)

I will look into this at some point. It's quite confusing loading eg. only Office 2007 hashes and getting the output Office, 2007/2010/2013 [SHA1 128/128 AVX 4x / SHA512 128/128 AVX 2x AES].

A change of algo name could be made in eg. reset() (which has knowledge about the loaded db) provided that would cut it for core. And of course some minor core changes could be made if needed.

Start by reading reset() and the core handling of algorithm names, then reproduce the Office 2007 output described in the issue with only one loaded hash type. Determine how loaded salt types, including uncracked hashes, should affect the displayed name; done means the name is specific when possible and remains correct for mixed types.