Gather experimental variants together

[jrapin]

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue

How Has This Been Tested (if it applies)

@teytaud the aim is to make the use of nevergrad simpler by only providing the main variantsof the optimizers.
All other optimizers can be created straightforwardly using the ng.families.DifferentialEvolution and other configurable classes.
On the other and, for the experiments, all variants are loaded

Checklist

• The documentation is up-to-date with the changes I made.
• I have read the CONTRIBUTING document and completed the CLA (see CONTRIBUTING).
• All tests passed, and additional code has been covered with new tests.

[teytaud]

if I understand correctly, this is moving, not breaking, so imho just go ahead and we'll see in the long run if we fill that some algorithms should be moved elsewhere.

[jrapin]

if I understand correctly, this is moving, not breaking, so imho just go ahead and we'll see in the long run if we fill that some algorithms should be moved elsewhere.

It's partially breaking: all the optimizers in experimentalvariants wont be available in ng.optimizers, and will only be registered in the optimizers registry if they explicitly import the module beforehand.
This is to avoid people getting lost with hundreds of variants and not knowing which one to use. Eventually we want to keep only the most important variants available, and promote the configured optimizers (with nice docstrings) so they can build the variants on their own that perfectly meet their needs