Expand IBAN interface

[okj579]

Here I've:

• Added implementations of bankAccountNumber to all existing, supported locales
• Made made the iban() function public
• Allow null as the $countryCode (where it chooses a random, supported country)
• Added unit tests for all supported countries

This allows the explicit use of iban() for any locale and allows for the generation of IBANs from random countries.

The unit tests also warn (skip tests) about locales where bankAccountNumber is not implemented, even though an IBAN format is available. This currently warns about the "fake" locales at_AT and be_BE, which are deprecated in #594.

The one point I'm not sure on is the default value of iban($countryCode). I've set it to the current locale for IBAN countries and null (random) on the base class. For example, it would currently work like this:

Faker\Factory::create('it_IT')->bankAccountNumber; // 'IT66F5186468682C65NOP68ZYK9'
Faker\Factory::create('it_IT')->iban; // 'IT04U8856763833CPN8P3H3QDJ4'
Faker\Factory::create('it_IT')->iban(null); // 'AT681337042751049061'

Faker\Factory::create('en_US')->iban; // 'HR6628746829188144538'
Faker\Factory::create('en_US')->bankAccountNumber;
// InvalidArgumentException with message 'Unknown formatter "bankAccountNumber"''

[fzaninotto]

Great work! But I'm worried about the duplication of formatters (iban and backAccountNumber). Rather than making iban public, why don't you rename it to backAccountNumber and ban the iban formatter altogether?

[nineinchnick]

That's why iban wasn't public in the first place. It's not a formatter, because not all countries use it. Many other formatters are bound to specific locale.

[okj579]

True, but it would lead to bankAccountNumber being available (as an IBAN) for non-IBAN countries, for example in the en_US locale, where returning an IBAN for bankAccountNumber would be wrong. A new formatter for en_US could be written, but then it would have to be overwritten in every locale to prevent them from returning misleading values. IBANs would also once again be unavailable for many locales.

After looking at the example above again, I have another idea. I could make iban only available as a function call (not a property) with the $countryCode mandatory (explicit null allowed). This removes a lot of duplication of functionality between iban and bankAccountNumber.

[fzaninotto]

yep, I like your latest suggestion.

[okj579]

iban() is now only available as a function call and the country code is mandatory. For a random country, null can be passed.

[nineinchnick]

Shouldn't array_rand be called on $ibanFormats keys, instead of values?

[okj579]

array_rand returns the key.
http://php.net/manual/en/function.array-rand.php

[nineinchnick]

Right, I've missed that. BTW, maybe self::randomKey() should be used here? @fzaninotto often comments that mt_rand gives better randomness than lots of built-in shuffling PHP functions.

[fzaninotto]

yep, array_rand() is verboten: it doesn't use the Mersenne Twister randomizer.

[okj579]

Alright, I've switched it to self::randomKey

[fzaninotto]

Thanks a lot!

[soullivaneuh]

This PR fixes a blocking error:

  [Symfony\Component\Debug\Exception\ContextErrorException]                                                                                        
  Warning: call_user_func_array() expects parameter 1 to be a valid callback, cannot access protected method Faker\Provider\fr_FR\Payment::iban()  

Could we have a new patch tag for this?