multibit2john.py should try not to output a "hash" for wrong input

Here are some assorted notes about multibit2john.py (and a bit about the corresponding format).

multibit2john.py was introduced by @kholia in #2548. There's an attached file with sample wallets in there. We do not have those in the john-samples repo yet - we need to add them to there.

There are 3 kinds of those wallets/keys supported:

1. $multibit$1 are essentially openssl enc with MD5 and AES-256. Indeed, the sample from btcrecover (btcrecover/btcrecover/test/test-wallets/multibit-wallet.key, which by the way we don't have in john-samples) is crackable with password btcr-test-password by both multibit2john.py + john or openssl2john.py + john (with the correspondingly different formats). However, the latter also produces a flood of false positives. Maybe there's room for improvement/unification based on this understanding.

2. For almost any unidentified file format, multibit2john.py happily produces a $multibit$2 hash. The only sanity check is based on filename, and it does not stop the program even if the filename doesn't contain the expected substrings - it merely prints "Make sure that this is a MultiBit HD wallet!", which isn't even clearly worded as a warning. We ought to do better, but looking at 3 sample files in @kholia's archive referenced above (one of which is the same as btcrecover/btcrecover/test/test-wallets/multibithd-v0.5.0/mbhd.wallet.aes) there doesn't appear to be a signature we could check for. The best idea I have is to require that the file size be a multiple of 16 (AES block size) and maybe that it's also in a reasonable range (the samples are all around 25K, but maybe that's a baseline size for nearly-empty wallet and it grows with use?)

3. We use btcrecover-derived code for $multibit$3, including a pre-generated protobuf parser in protobuf/wallet_pb2.py. I wonder if we should sync this with upstream once in a while. This file is now btcrecover/bitcoinj_pb2.py upstream, so we could take it from there and adopt the rename, too. Its content changed quite a bit, but that could be a result of its regeneration with newer compiler.

Start with multibit2john.py and the sample wallet paths mentioned in the issue, then compare its handling of the three wallet types and unidentified files. Check the referenced MultiBit and btcrecover samples; done means wrong input is rejected without emitting a hash, while supported wallet samples continue to produce usable output.