Appropriate error message if search string is longer than supported

[nikhilbhardwaj]

When invoked with a string longer than 10 characters, the current messaging isn't clear. Here's what I'm seeing -

➜  Downloads wireguard-vanity-address longerthanten
searching for 'longerthanten' in pubkey[0..23], one of every 0 keys should match
one trial takes 46.1 us, CPU cores available: 4
est yield: 0.000 ps per key, infe9 keys/s
hit Ctrl-C to stop

It's not clear if there won't be a match ever or if it'll take forever. I think we should have better messaging if we don't look for more than 10 characters then this could be an appropriate error message, otherwise an estimate like for shorter strings should be made available (even if it's a very long one).

[warner]

Hm, yeah, that is confusing. I'm looking at the code and I can't remember what it's supposed to be doing. There's a --range= argument that lets you control how picky it is: the default is that the string you provide must start within the first 10 characters of the base64 public key. But internally, it computes a start (always 0) and an end (10, or length+10, or range), and requires that your string appear within pubkey[start..end].

I think that range clause is inconsistent with the rest. I think we should say that range means "your string must start within the first RANGE characters" (instead of having it sometimes mean "your string must appear within the first RANGE characters), have it default to 10, and then compute end to match. Then the only completely illegal case is if your string is more than 44 characters long (since that's the length of a base64-encoded public key, so it could never match). Of course anything more than about 10 characters would take years to find a match, but we should be able to quantify that a bit and provide a more understandable estimate.