Propagate AnonymizerConfig into AbstractAnonymizer

[pounard]

Followup of #226.

The idea is to propagate AnonymizerConfig directly to AbstractAnonymizer constructor, instead of de-structuring it as $table and $column parameters.

This has many advantages:

• Each time we add new parameters into AnonyizerConfig then AbstractAnonymizer::__construct() will remain stable (no refactoring needed).
• All anonymizer may use AnonyizerConfig properties, and thus gain flexibility.
• Later file enum and file column anonymizers will require the base path information from fix #226 - base path in AnonymiationConfig and related documentation #232 to load data files.

Disadvantages:

• This is a AbstractAnonymizer::__construct() signature change, which means a breaking change.
• The PR will be huge, there are many places to fix (especially unit tests).

Another question remains: could we actually allow this breaking change to be in a minor version? My opinion is yes, because people extending the AbstractAnonymizer class or any of the existing subclass are likely not needing to change the constructor implementation, and they don't instanciate their code themselves since it's the role of the AnonymizerRegistry class.

[pounard]

Another option for passing new parameters would be to pre-populate options with a set of "global" options directly when the registry creates the anonymizers.