Pretty-printing as utility methods

[TheConstructor]

These two commits aim to better support evaluation of user input data.

• CountryCodes.SHORTEST_IBAN_LENGTH and CountryCodes.LONGEST_IBAN_LENGTH can be used to find the right dimension for input fields
• IBAN.toPretty() reformats user-input without validation to assist user in finding typos (especially if user entered IBAN without spaces)
• Removed country-code-pre-check in IBAN-constructor as CountryCodes.getLengthForCountryCode() already rejects he filtered values and some more
• Reduced length check in IBAN-constructor to a minimum of 5 as CountryCodes.getLengthForCountryCode() may some day return 14 and this way only one place needy to be changed; 4 could be argued as well, but I guess there will never be a country with just one bank account...
• Switched from String.replaceAll() to pre-compiled pattern (same semantics, possibly faster)

[barend]

Thanks! The code looks good and the tests are passing, that's all cool. It's been a while since I looked at this library, I need to sleep on your changes.

The functionality is fine and I'm happy to include it, but the thing that I'm pondering is whether I want to keep the toPretty/toPlain methods in IBAN or move them to a utility. On the one hand, IBAN is a nice and short namespace, on the other, the methods aren't dealing with IBAN objects at all, just strings that may just as well be alphabet soup.

At the time I got distracted I was exploring ways to facilitate input processing. This factors into that. There's the experimental/lenient branch where I stumbled on the clunky naming and I have a local branch where I was looking into variations of the builder pattern.

If I don't have an epiphany on that front overnight, I'll merge your pull request and prepare a new release to maven central.

[TheConstructor]

Thank you!